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

[Daniel Golle]

Hi!

On Tue, Mar 08, 2016 at 08:39:49PM +0100, Christian Grothoff wrote:
> 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 ;-).

Push-talk like communication with a few seconds of delay is totally
fine if you got a 'end-of-transmission'-button (or habbit).
It doesn't have to be phone in the way everyone is used to it
(full-duplex, less than 100ms end-to-end delay). I just like the
simple analog UI, numberical input via in-band DTMF and all that...

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

The point for me is kinda that I believe they highly overlap and if
designed smartly, redundant code or heavy re-writes in later stages
could be avoided. Speaking with SIP-to-PSTN gateway or the actual
PSTN (via PRI-over-ATM or whatever) is very similar to pretending
to be the post-office offering a dialtone to good old phones. 

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

That assumes that you are using the same gateway for both, incoming
and outgoing calls or you have to invent a method to authenticate
the outgoing gateway to get the actual POTS number from the incoming
gateway. Though these jobs are technologically related, the markets
for incoming (DID) POTS usage is very different from the markets for
outgoing calls, also in terms of regulation and with still quite
significant local differences (depending on call destination as well
as available payment methods, guaranteed call quality, ...).

It also makes the gateways store all numbers they ever
handled more or less permanently, which is not such a good idea imho.
I believe that the more advanced technology should always allow
addressing or mapping the previous technological age without creating
negative impacts in terms of security/privacy.
On rule to achieve that seems to be to have legacy gateways store as
little as possible, as usually there aren't many of them and they
tend to be not the most loved or well-maintained things in the world...

An ideal new-world will imho always contain the old-world, it just
won't be that significant any more (because it's in a room in a
museum for children to learn about the past).


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

Upstream asterisk will most likely never support OPUS for legal reasons
as described on the asterisk-opus github README.md. However, as I
believe that the patch can easily be merged to the Asterisk package e.g.
on OpenWrt, and that would open doors to some hardware support for FXS
ports on some embedded systems.
On the other hand, one could also just implement a
SIP/RTP-to-GNUnet-conversation-proxy running on localhost and use it
with whatever is feasible (no necessarily asterisk).
Right now I'm considerting to tunnel IAX2 through gnunet-vpn, but
that's only good for the legacy-PSTN-gateway cases and not for the
connecting-analog-handsets case. (Tunneling SIP through gnunet-vpn is
infeasible because it requires random RTP ports being mapped for each
call...).


> Happy hacking!

Very much. Same to you :)


Cheers


Daniel