[GNUnet-developers] integrating traditional VoIP (and thus the PSTN) with gnunet-conversation

[Daniel Golle]

Hi!

One of the main reasons I'm not yet using gnunet-conversation as my
main tool for real-time voice communication is it's lack of
integration with the POTS.

There are two aspects to this:
* Using FXS interfaces on embedded devices (VoIP routers) to connect
  old-school phones and routing the calls via gnunet.
* Tunneling calls to traditional POTS via gnunet-conversation, like
  SkypeOut and such.

I'm personally more interested in the first application, and look
forward to hints or opinions on implementing this. I like analog
phones and simple embedded devices as the amount of code and
complexity is very limited, there aren't millions of layers of
different libraries with tons of possible vulnerabilities...

I imagine that GNS could be used to e.g. store e164.arpa records,
thus I could easily have my local numerical phone-book and use my
analog phone to call friends on gnunet-conversation 

To handle the 'connect-with-the-POTS' case, we will need a way to
transport a POTS-number with the call, so a gnunet-conversation-2-POTS
gateway can know which number on the POTS one wanted to call and in
case of an incoming call, it'd be nice to signal the caller-id of the
caller as seen by the gateway.
I saw there is the LINE parameter, and I wonder if it is suitable to
deliver E.164 numbers (which can be long) for outgoing calls to the
POTS. What is the intented of the LINE field? (the description in
conversation.conf makes me think that it could be useful for
embedded devices with 2 or more FXS interfaces)

Signinalling the callerid will need something similar, but supposedly
abusing the same field for that would not be such a good idea.

In practice, OPUS is hardly supported in any of the traditional VoIP
software. I found this patch for Asterisk
https://github.com/meetecho/asterisk-opus
Writing an asterisk channel driver for gnunet-conversation seems to be
the most feasible and generic approach to solve both the above.
It'd obviously be more elegant to have proper OPUS support in Asterisk
and let it handle pass-through and recoding when really needed...
If that really won't work, gstreamer can handle the recoding to slin16
inside the gnunet-conversation channel driver...

I'm willing to put some time and effort into drafting/prototyping.
I guess I do have quite some experience with hacking asterisk and other
SIP/VoIP stuff.


Cheers


Daniel