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

[Christian Grothoff]

On 03/08/2016 03:53 PM, Daniel Golle wrote:
> 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.

Ok, that's surprising. My guess would have been the counterintuitive GUI
or the latency issue(s), but I'm happy to be told otherwise ;-).

> 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...

Sorry, don't know enough to say which one is more
important/relevant/easier to do.

> 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 

Sure, you could easily create a "POTS" record type for GNS.

> 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)

The idea behind LINE was that you may have multiple phones associated
with one peer. It could be that I have a business and a personal line,
or that there are multiple users sharing one peer, i.e. because the peer
is on a NAT box and they share the LAN.

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

The key question is what do we want to use it for? For calling back,
maybe we should let the POTS gateway take care of it with a persistent
internal table: it puts its own external number (XXX) plus a number EXT,
and *internally* creates a mapping between EXT and the GNS caller ID
(i.e. the PHONE record).  That way, the callerID can become meaningful
for calling someone back.

> 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.

Great, I don't, so I really cannot say what the ideal strategy is, but
having Asterisk support OPUS sounds like something one might want
anyway, and thus a good idea to me.

Happy hacking!

Christian

signature.asc
Description: OpenPGP digital signature