Greetings,

I've been an Asterisk developer for a few years. I now lead the software team in charge of Asterisk at Digium, Inc. I just learned about Pd a few weeks ago when I met Hans. I think Pd is very cool, and I'm really excited to see what we can come up with to combine Pd and Asterisk.

I have been diving in head first to learn about how Pd works, and what the possibilities could be. However, I would like to discuss what the goals of "Pd

• Asterisk" are.

Coming up with the most powerful integration between the two will take two parts:

1. What are the potential applications that we can dream up? I can provide

access to any aspect of a phone call. That includes the media streams and various bits of meta-deta, such as the digits that have been pressed. What can those of you that have the real knowledge about Pd think of that would be cool to do with a phone call?

2. Given the applications above, what are the primitives required to accomplish

them? Both Asterisk and Pd are toolkits. It's all about breaking things down to a general solution that is the most flexible to accomplish current and future applications.

Hans-Christoph Steiner wrote:

Fun stuff, three of these. I had been vaguely thing of making some
kind of AGI object for Pd. It would be nice to easily tap into
Asterisk from Pd.

Just a quick bit of background. AGI is an interface that exists in Asterisk to use the programming language of your choice to control phone calls. It uses stdin/stdout or a TCP socket to send/receive text commands and responses.

I'm not sure that this interface makes sense for Pd. It's tempting to see if we can fit into something that exists, but my gut is telling me that Pd is a different animal that should be approached in a different way.

A softphone that uses Jack would be handy too... on that note, I
wonder how hard it would be to make a softphone in Pd :)

A softphone in Pd? Ha ... I suppose it's possible. We can come back to this one. ;)

For now, I think I'd rather start with hooking Pd into Asterisk so that it becomes a part of a larger system. Asterisk can handle the phone calls part, and Pd gets to do what it is good at already.

I've been looking at [streamin~]/[streamout~] a bit this weekend. I am thinking of using that as an initial proof of concept to get audio from a phone call in and out of Pd. But, please yell at me if there is something else I should start with. In the end, I want to provide a couple of different things in regards to phone audio.

1. I want to make it possible to develop interactive phone applications using

Pd. Basically, I want the audio from a call to go into Pd, and to get audio back out that is sent back in the caller.

2. I also want to be able to hook Pd into the audio path of a call. So, the

audio coming from one side of the call is processed through a Pd patch before sent out to the other side of the call.

Finally, aside from the audio of a call, I want to be able to pass events into the Pd patch, as well. The first part of this would be any digits pressed on the phone, but there could be other things. Some telephony technologies allow text messages to be sent within a call, for example.

Anyway, those are just some initial thoughts. Let your mind wander, though. Telephones are everywhere, especially now that so many people carry cell phones. What could that mean for people using Pd in performances? interactive art projects? If you have some ideas, what can I do to make it possible? Just let me know. :)

-- Russell Bryant

drh270 wrote:

This sounds great!

Cool, thanks for the interest. :)

Chris, in an earlier post mentioned using OSC, he was using a Python script, so communicating via OSC may be a starting point.

Yeah, I saw that. Thanks for bringing up OSC again. The trick is going to be to have a real-time interface that provides both media and call signaling access. I could put together a native interface in Asterisk for OSC so that digit presses could be sent out as OSC messages. Then, optionally, at the same time, the audio could be flowing in and out of Pd, as well.

Seems to me that perhaps a SIP soft phone may be trickier because rtp audio comes in on many ports, what about a Pd iax2 phone object and have it listen to the audio on port 4569?

SIP is definitely much more complicated than IAX2, and you won't see me writing a SIP interface. I would definitely go for IAX2. However, I would say that it's not quite for the reason that you mentioned. For RTP with SIP, ou always know what port the audio is going to come in on, because you're in charge of picking it.

One issue that is on my mind, is scalability. It's clear to me how I could implement a Pd patch that could process 1, 2, 3, ... calls, but it is not yet clear to me how it could support any number N calls, up to what the network and processing power can support. However, it may be just be that my Pd knowledge is still very lacking. :)

Is it possible to run Pd and Asterisk on the same machine? Like Icecast?

Sure. There should be no problems with that.

-- Russell Bryant

On Dec 2, 2007, at 8:19 PM, Russell Bryant wrote:

drh270 wrote:

...

This sounds great!

Cool, thanks for the interest. :)

...

Chris, in an earlier post mentioned using OSC, he was using a Python script, so communicating via OSC may be a starting point.

Yeah, I saw that. Thanks for bringing up OSC again. The trick is
going to be to have a real-time interface that provides both media and call
signaling access. I could put together a native interface in Asterisk for
OSC so that digit presses could be sent out as OSC messages. Then, optionally,
at the same time, the audio could be flowing in and out of Pd, as well.

...

Seems to me that perhaps a SIP soft phone may be trickier because rtp audio comes in on many ports, what about a Pd iax2 phone object and have it listen to the audio on port 4569?

SIP is definitely much more complicated than IAX2, and you won't
see me writing a SIP interface. I would definitely go for IAX2. However, I would
say that it's not quite for the reason that you mentioned. For RTP with
SIP, ou always know what port the audio is going to come in on, because you're in
charge of picking it.

One issue that is on my mind, is scalability. It's clear to me how
I could implement a Pd patch that could process 1, 2, 3, ... calls, but it
is not yet clear to me how it could support any number N calls, up to what the
network and processing power can support. However, it may be just be that my
Pd knowledge is still very lacking. :)

That is Pd's weak point in general: multiple instances of processes.
Since everything running has a physical representation, that means
that each instance of a call in Pd would need it's own physical
representation in Pd. Currently, it isn't possible to load a new
patch without an interruption in the DSP. That interruption could be
just a click, but it's there nonetheless.

Whenever I need something that dynamically allocates new voices,
which is probably the most common Pd parallel to Asterisk's calls, I
use an "nqpoly4" which pre-allocates a number of instances of the
objectclass I am using. Then messages to processed are sent to that
already existing pool. It works well, in practice, but it is not
very resource-efficient.

There has been talk in the past about some optimizations that would
allow dynamic allocation without the interruption, but not a lot of
work done in that regard since it's pretty complicated. In
particular, the ideas I remember were building a new DSP chain in the
background, then swapping it in. The other was figuring out how to
only rebuild the parts of the DSP chain that changed.

.hc

As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin

On Dec 3, 2007, at 3:06 AM, cdr wrote:

...

There has been talk in the past about some optimizations that would allow dynamic allocation without the interruption, but not a lot of work done in that regard since it's pretty complicated. In particular, the ideas I remember were building a new DSP chain in the background, then swapping it in. The other was figuring out how to only rebuild the parts of the DSP chain that changed.

Nova [0] and Ingen [1] figured this out. along with countless other
DAWs and media engines

incidentally theyre all written in C++ rather than C, properly- threaded, use high quality 3rd party libraries throughout, and
written by hackers rather than mathemusicians.

For all it's faults, Pd has the advantage of having 10+ years of use,
testing, library development, etc. DAWs are a very different story
since they are not programming languages.

Ingen also has a notion of polyphony at multiple levels, such as
plugin or subpatch, transparent to any machinations in the subpatch
or plugin to fake native polyphony via preallocation and routing
schemes.

or if asterisk can talk to jack, sprouting a new PD per-call seems
the most plausible, in terms of using PD rather than libingen/nova
(ie, not fighting for polyphony or dynamically sprouting jack ports
from an existing instance)

This does sound like a possibility from the point of view of handling
a unknown number of instances. I think that pd -nogui should be
light enough to support this. The downside is that it would make
difficult to have interactions between calls (if each call was
running a patch in its own Pd process). I suppose that Asterisk
could provide a means for communication between these Pd processes.

Now that I think about it, it would also work to have each call open
an instance of a patch within one constantly running Pd process.
Then when the call is dropped, that patch instance would close. For
this to work well, we'd need to add the ability for a patch to close
itself programmatically (currently, when a patch sends menuclose to
itself, Pd crashes :( )

.hc

[0] https://tim.klingt.org/nova/ [1] http://drobilla.net/software/ingen

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli

Russell Bryant wrote:

Hans-Christoph Steiner wrote:

...

Now that I think about it, it would also work to have each call open
an instance of a patch within one constantly running Pd process.

just to make sure: you are not talking about creating a system that would do that for me as "the" way to use asterisk with Pd?

i think all it needs is an object that tells me that there is a new incoming connection and how to access it (that would basically just be an ID which can then be used to get the actual data; nevermind whether it is creating a new [streamin~] object, connecting to a new jack-port or just thawing a frozen part of the patch.

...

Then when the call is dropped, that patch instance would close. For
this to work well, we'd need to add the ability for a patch to close
itself programmatically (currently, when a patch sends menuclose to
itself, Pd crashes :( )

just to re-iterate: i think you are planning on the wrong level. what you are planning seems to be a full-featured environment that does all kind of thinks for you. if i understood the problem correctly, we are not there yet; what, imho, has to be done first is creating an as simple as possible way to access the data from Pd. generative patches are most likely way to highlevel for this. once we have this low-level API, somebody could go and create the environment you are currently dreaming of.

somebody else, could go and create an other environment, that fits their needs better.

Yes, that would certainly be the ideal way to do it. In fact, instead of messing around with multiple Pd processes, I would much rather just help solve whatever the problem is that causes this not to work.

i agree that multiple Pd instances are not the way to go.

as i have said, i would keep it as simple as possible, and as general as possible: my suggestion for asterisk is to use jack for dealing with the audio lines. 2 ways come into my mind:

• open a new jack-port (in asterisk) for each call ; leave the

application to handle this (on the Pd side this is simple; one can redefine the audio-api (e.g. jack-ports used) at runtime; one would then need an external (most likely already written by kjetil) to do the jack-routing)

• start with a fixed number of jack-ports (maximum number of

simultaneous calls) in asterisk; pre-connect all jack-ports from asterisk to Pd and switch~ on/off patches for each line as they are opened/closed. i guess for many projects this super-simple approach will be totally sufficient.

both of these ideas seem to be simple to implement and have the biggest overall advantage, not just for Pd, but _also_ for Pd, as they are far more simple to use than anything that does things automatically.

mfga.sdr IOhannes

On Dec 3, 2007, at 11:42 PM, Russell Bryant wrote:

Hans-Christoph Steiner wrote:

...

Now that I think about it, it would also work to have each call open an instance of a patch within one constantly running Pd process. Then when the call is dropped, that patch instance would close. For this to work well, we'd need to add the ability for a patch to close itself programmatically (currently, when a patch sends menuclose to itself, Pd crashes :( )

Yes, that would certainly be the ideal way to do it. In fact,
instead of messing around with multiple Pd processes, I would much rather just
help solve whatever the problem is that causes this not to work.

Are there any existing bug reports or any previous discussions
about the problem?

The discussion on this bug talks about the issue, which also happens
when you send a "clear" message to a patch from within that patch.

http://sourceforge.net/tracker/index.php? func=detail&aid=1518030&group_id=55736&atid=478070

I agree with sistisette on this discussion, but it's not a cut and
dry issue, as you can probably see :). For me, unless someone
demonstrates the harm in adding the possibility for deleting a chunk
of a tree that is executing (I mean besides the crash ;), then I
think it should be possible, especially since it would mean that
patches could close themselves, which is a very useful thing.

.hc

Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli

On Dec 2, 2007, at 8:19 PM, Russell Bryant wrote:

drh270 wrote:

...

This sounds great!

Cool, thanks for the interest. :)

...

Chris, in an earlier post mentioned using OSC, he was using a Python script, so communicating via OSC may be a starting point.

Yeah, I saw that. Thanks for bringing up OSC again. The trick is
going to be to have a real-time interface that provides both media and call
signaling access. I could put together a native interface in Asterisk for
OSC so that digit presses could be sent out as OSC messages. Then, optionally,
at the same time, the audio could be flowing in and out of Pd, as well.

OSC sounds like a good interface for the messaging since it's not too
complicated and is pretty well supported. One thing that might be
nice to have in the Asterisk OSC is the time-tagged messages. Most
OSC implementations ignore that part of it, unfortunately, but I
think it could be useful to have when syncing different parts, like
if one program was processing audio and another handling video.

.hc

...

Seems to me that perhaps a SIP soft phone may be trickier because rtp audio comes in on many ports, what about a Pd iax2 phone object and have it listen to the audio on port 4569?

SIP is definitely much more complicated than IAX2, and you won't
see me writing a SIP interface. I would definitely go for IAX2. However, I would
say that it's not quite for the reason that you mentioned. For RTP with
SIP, ou always know what port the audio is going to come in on, because you're in
charge of picking it.

One issue that is on my mind, is scalability. It's clear to me how
I could implement a Pd patch that could process 1, 2, 3, ... calls, but it
is not yet clear to me how it could support any number N calls, up to what the
network and processing power can support. However, it may be just be that my
Pd knowledge is still very lacking. :)

...

Is it possible to run Pd and Asterisk on the same machine? Like
Icecast?

Sure. There should be no problems with that.

-- Russell Bryant

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

Access to computers should be unlimited and total. - the hacker ethic

I am also quite excited about this, I think it can provide some
really interesting new ways of interacting with phones, possibilities
for composition, or whatever else we can dream up. I am really into
the idea of live audio processing of phone calls then feeding back
synthesized audio into the phone call.

On Dec 2, 2007, at 3:45 PM, Russell Bryant wrote:

I've been looking at [streamin~]/[streamout~] a bit this weekend.
I am thinking of using that as an initial proof of concept to get audio from a
phone call in and out of Pd. But, please yell at me if there is something else I
should start with. In the end, I want to provide a couple of different things
in regards to phone audio.

I just had a thought about this, perhaps it would make more sense to
make Asterisk use Jack (http://jackaudio.org/) as the interface for
transferring audio to Pd. It's a common standard, it runs on GNU/ Linux, Mac OS X, is alpha on Windows. It would allow Asterisk to
interface with a wide range of audio apps that support Jack. AFAIK,
you can dynamically allocate and deallocate jack "channels". There
is already some support for managing the jack channels in Pd, and I
don't think it would be too hard to support.

So the idea would be that for each call that is sent to Pd, it would
open up a jack channel and notify Pd about it. The question there is
whether Jack can support hundreds or thousands of channels.

.hc

There is no way to peace, peace is the way. -A.J. Muste

On Mon, 2007-12-03 at 22:39 -0600, Russell Bryant wrote:

Hans-Christoph Steiner wrote:

...

I just had a thought about this, perhaps it would make more sense to make Asterisk use Jack (http://jackaudio.org/) as the interface for transferring audio to Pd. It's a common standard, it runs on GNU/Linux, Mac OS X, is alpha on Windows. It would allow Asterisk to interface with a wide range of audio apps that support Jack. AFAIK, you can dynamically allocate and deallocate jack "channels". There is already some support for managing the jack channels in Pd, and I don't think it would be too hard to support.

So the idea would be that for each call that is sent to Pd, it would open up a jack channel and notify Pd about it. The question there is whether Jack can support hundreds or thousands of channels.

Yeah, I really do like the Jack idea. I think this is going to be the way to go. Now that I'm looking at it, I'm really quite surprised that nobody has already written a Jack interface in Asterisk. So, I guess this is where I'll start.

Thanks for the pointers. :)

a colleague from school once created a setup that involved asterisk and pd (i don't know, why he's actually not responding to this thread....). he ran asterisk over oss2jack in order to use jack to establish an audio connection between them. if asterisk would directly have access to jack, that would be awsome of course.

roman

Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Chris wrote:

extensions.conf:

[default] exten => 5599,1,Set(TIMEOUT(response)=300) exten => 5599,2,Set(TIMEOUT(digit)=300) exten => 5599,3,Answer() exten => 5599,4,Read(digit,beep,1) exten => 5599,5,System(/path/to/osc.py 127.0.0.1 10000 ${digit}) ; HOST, PORT, VALUE exten => 5599,6,Goto(4) exten => 5599,7,Hangup

The digit is sent to the /sip message.

In Pd you would use something like: [dumpOSC 10000] | [OSCroute /sip] | [print]

Cool, thanks for sharing!

As I mentioned in another response to this thread, I'm going to try to make an interface like this that is native to Asterisk. Then, I'd like to extend it further so that audio (and video) processing of the call could be in done in Pd, as well.

If you have any ideas about what you'd like to see, please let me know.

-- Russell Bryant

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

This is great news! I am going to give it a shot as soon as I can,
hopefully before the end of the year.

As for Jack in Pd, there are a couple of things. Pd by default uses
Jack as an audio device, so it should be able to see those ports.
But I don't think that is very controllable from within Pd. There
are some objects that exist but aren't widely used that are for
connecting Pd and jack channels in a more dynamic manner. Here are
the sources:

http://pure-data.cvs.sourceforge.net/pure-data/externals/jackx/ http://pure-data.cvs.sourceforge.net/pure-data/externals/k_jack~/ http://pure-data.cvs.sourceforge.net/pure-data/externals/tb/ jack_transport/

And thanks for the bug fixes for Pd. Pd could use a good security
audit, especially since it is becoming more and more network aware.

.hc

On Dec 16, 2007, at 8:48 PM, Russell Bryant wrote:

Greetings,

I have been working on Jack support in Asterisk this weekend and I
have it working, as far as I can tell. I have a Jack Asterisk dialplan
application which when executed, creates two jack ports; one port is input and
the other is output. These ports let you access the audio that comes from the
caller, as well as control what audio gets sent back to the caller. Once I
have this working well, I will extend the Jack interface to allow you to do
fancier things. Right now, the jack interface is the endpoint of the phone
call, but it would be even more interesting to be able to hook into the audio
path of a phone call to another destination.

Anyway, the way that I have tested this is simply by using an
application called "Patchage". It is a graphical jack port manager. When I make a
call, I see my two jack ports appear. I can connect them together and everything
I say gets sent back to me as expected.

My next step is that I want to figure out how to hook up my ports
to a Pd patch, but I haven't quite figured out how to use Jack in Pd yet. I'm
going to keep working on it, but I figured I would post what I have in case
anyone else was curious and interested in trying it out.

Here is what I'm doing to test what I have ...

1. Install my branch of Asterisk that contains app_jack.

$ svn co http://svn.digium.com/svn/asterisk/team/russell/jack
asterisk-jack $ cd asterisk-jack $ ./configure && make $ sudo make install

The jack interface is in apps/app_jack.c in case anyone cares.

2. Make an entry in /etc/asterisk/extensions.conf that looks like

exten => 500,1,Answer() exten => 500,n,Jack()

3. Make sure jackd is running. For the sake of efficiency, specify

8 kHz, because for most codecs used for phone calls, that's all you get.
Also, specify 160 frames per period. For 8 kHz audio, this comes out to 20 ms
periods, which is generally the packet size used for Voice over IP.

$ sudo jackd -d dummy -r 8000 -p 160

4. Make a call to the extension created in Asterisk in step 2. You

should see the two new jack ports become available. In theory, they are
available for connection to any application that can use Jack. The only thing I
have done so far is to use the "patchage" application to connect the ports
directly together to verify that the audio is flowing correctly.

Now, to figure out how to hook up arbitrary jack ports to Pd ... if
anyone has any pointers, it would be much appreciated. I'm still very new to
Pd. :)

-- Russell Bryant

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore

Hey,

thanks for this, I just tried it, it works (kind of)...

1. Install my branch of Asterisk that contains app_jack.

$ svn co http://svn.digium.com/svn/asterisk/team/russell/jack asterisk-jack $ cd asterisk-jack $ ./configure && make $ sudo make install

The jack interface is in apps/app_jack.c in case anyone cares.

There was the first problem, app_jack somehow didn't build without any errors, configure said jack...h was there, but there was no app_jack.so build. I had to do a 'make menuconfig' and disable+reenable app_jack.

3. Make sure jackd is running. For the sake of efficiency, specify 8 kHz,

because for most codecs used for phone calls, that's all you get. Also, specify 160 frames per period. For 8 kHz audio, this comes out to 20 ms periods, which is generally the packet size used for Voice over IP.

$ sudo jackd -d dummy -r 8000 -p 160

I used 128 frames, this sounded a bit better. But I think it would be much better if app_jack would adapt to the running jack. I sometimes use jack for connecting to a firewire-soundcard and with 8KHz it's impossible to have good sound out of your speakers ;)

4. Make a call to the extension created in Asterisk in step 2. You should see

the two new jack ports become available. In theory, they are available for connection to any application that can use Jack. The only thing I have done so far is to use the "patchage" application to connect the ports directly together to verify that the audio is flowing correctly.

I tried Pd and had some strange problems (I don't know where they come from) No problem if you connect adc~ from Asterisk to dac~ on Asterisk, I hear myself with a rather extreme echo. But I can't hear a simple osc~ on the phone, neither can I hear myself on my PC-speakers when I talk into the phone.

Now, to figure out how to hook up arbitrary jack ports to Pd ... if anyone has any pointers, it would be much appreciated. I'm still very new to Pd. :)

You could do this in Asterisk with a System(jack_connect ...) ;) Do you think it would be possible to tell app_jack to connect to jack-server running as Pid x? Jack sometimes screws up your system when it runs as root, or other software does, because it has to run as root too. I configured my Asterisk to run as myself, but that's quite complex.

Anyway, it's cool you coded all this, thanks.

-Chris