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
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
