gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christian Grothoff
Subject: Re: [GNUnet-developers] integrating traditional VoIP (and thus the PSTN) with gnunet-conversation
Date: Wed, 9 Mar 2016 08:59:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 03/09/2016 01:11 AM, Daniel Golle wrote:
>>> 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, ...).

Ok, I didn't know that. Still, sounds like one could force those two to
be the same entity, or to simply not offer call-back functionality.

> It also makes the gateways store all numbers they ever
> handled more or less permanently, which is not such a good idea imho.

Nah, the storage is not even a concern. You can run this for years
without storage trouble.  The issue is more that you want to limit the
length of the extension (I assume reasonable caller IDs cannot have 100
digits), so you'll have some LRU recycling scheme of the numbers where
you re-use the one that you haven't seen the longest. But, as phone
numbers in the POTS world are not 'stable' forever anyway, that should
be OK as well.

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

Sure, but is a caller ID with 256+ bits feasible? I'm not sure you can
have that many digits in POTS, and even if you did, would it really
work?  I don't think you can get cryptographic security with (practical)
POTS numbers.  Besides, the gateway gets to decrypt your call, and gets
to route it. So you do need to trust it anyway.

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

Oh, really. Well, "due to legal reasons" isn't really explaining much as
to why, and it didn't say this could not change. Regardless, the patch
exists, that might be good enough for now.

Happy hacking!

Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]