[asterisk-users] Asterisk support for Bittorrent Bleep
farid at bittorrent.com
Wed Aug 13 14:30:07 CDT 2014
On Wed, Aug 13, 2014 at 9:39 AM, Matthew Jordan <mjordan at digium.com> wrote:
> On Mon, Aug 11, 2014 at 10:46 AM, Farid Fadaie <farid at bittorrent.com>
> > Hello,
> > Full disclosure: my name is Farid Fadaie and I'm in charge of BitTorrent
> > Bleep (a private P2P SIP-based messaging application in early alpha)
> > I have personally been a fan of Asterisk and have been using it for years
> > and now that we have (kind of) released Bleep, I wanted to ask you guys
> > let us know what you think. Considering that Bleep is built on an engine
> > (think of it as a distributed SIP proxy) that supports SIP, I thought it
> > might be beneficial to ask you guys for your ideas.
> > Here is what I have in mind but will be happy to hear your thoughts on
> > everything that is relevant to Bleep and Asterisk:
> > 1- What do you think about supporting Bleep in Asterisk? Similar to Skype
> > channels but way more flexible (considering the interface will be SIP).
> > engine can take care of all lookups, NAT traversals, encryption, etc. We
> > essentially enable Asterisk connected devices to be able to talk to Bleep
> > users.
> The integration with Skype used a completely separate channel driver.
> Without any more information to show otherwise, I'd assume that since
> Bleep's protocol is SIP, both chan_sip and chan_pjsip would work "out
> of the box".
> Are there any specific technical differences between what Bleep and a
> "standard" upstream SIP provider would look like to Asterisk?
SIP-wise they should be the same. You can use a normal SIP softphone with
the engine (that's actually how we implemented this internally and test
it). Having said that, they are some non-SIP features like creating a new
user (done locally by creating a public/private key), authentication (for
non-incognito user) we very that they actually own the phone number/email
address, etc that can potentially be supported.
A simple (but probably not ideal) scenario is to just use the username
field (which works <= I tried it) but it doesn't scale.
One potentially better approach is for us to allow authenticating domains
(at this point we only support authenticating emails & phone numbers). With
domain authentication, companies which use Asterisk can authenticate their
domain and the Bleep network will route all SIP invites to that domain to
their Asterisk server. Then Asterisk can decide how to route the call
internally to clients that are attached to it.
In any case, my personal hack-y way of getting this to work is to run our
engine and Asterisk on the same machine and configure Asterisk to use
localhost as a SIP server. It probably makes more sense to enable Asterisk
to talk to our engine not through a UDP socket and ideally not require two
different processes (one for Asterisk and one for our engine).
> > 2- How could the Asterisk community benefit from Bleep (or the engine
> > it)?
> I'll defer that question more to users - but I'm sure there are plenty
> of people who are interested in secure communication!
> All links are encrypted. We are using secure encryption protocols
> such as curve25519, ed25519 , salsa20, poly1305, and others. Links
> between nodes are encrypted. All communication is end to end
> encrypted. This should be the new normal in the post-Snowden era.
> I think some more specific information about how things are encrypted
> would be useful. How do you see Bleep comparing against WebRTC, which
> has a similar distribution model for media? (Although signalling is
> not distributed; that's obviously a whole different conversation) Are
> you using DTLS-SRTP, or something else?
We are certainly going to answer most of these questions. We have been
extremely busy in finalizing the protocols and haven't had time to look
into how we can publish the information.
In a nutshell, here is how it works:
The SIP client (any SIP client) talks to the engine over SIP. We intercept
some of the SIP messages (like INVITE) and do a lookup to find the
destination's IP through a DHT lookup (unlike some other P2P solutions, we
do it in a manner that (IP, public keys) are not public so an attacker
cannot just correlate IPs to public keys. Once we find the destination's
IP, we create an encrypted tunnel between the two nodes and from that point
on, we forward most of the SIP/RTP verbatim through the tunnel). We handle
all NAT traversals (before establishing the tunnel) so that SIP peers don't
need to worry about it. We rewrite SIP headers in a way that makes it
seamless to the SIP endpoints.
> > 3- what features would you like to see implemented in Bleep (the consumer
> > app) or its engine?
> I'll defer that question more to users as well :-)
> > Let's see if we can come up with any interesting idea. Thanks in advance.
> So this definitely sounds very interesting. I think some more
> technical details about Bleep would be helpful for the Asterisk
> developers, so we could see what would be needed for Asterisk to
> communicate with Bleep.
Thanks for your input Matt.
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-users