[Top][All Lists]

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

[Gnucomm-privacy] Re: [Gnewsense-dev] Re: Secure VoIP calling - adoped b

From: David Sugar
Subject: [Gnucomm-privacy] Re: [Gnewsense-dev] Re: Secure VoIP calling - adoped by Fedora and Ubuntu GNU/Linux
Date: Mon, 30 Nov 2009 07:14:49 -0500
User-agent: Mutt/1.5.11

The barrier to calling "between" SIP providers is the one thing sipwitch
explicitly removes, along with requiring the explicit use of any mediating
providers.  This is because any sipwitch daemon can call an endpoint of any
foreign sipwitch daemon reachable through dns and finding users can then be
simplified to having their sip uri identity match their domain email address.
But this in itself does not answer questions of conferencing.

Multicast could be a wonderful solution for lots of things if it was routed
from the mbone all the way to users through ISP's.  It is not.  One solution
for conferencing, at least for secure audio, is to have each endpoint
establish a separate session with each participant, but clearly that can
become bandwidth intensive for more than a few.  One-to-many is in theory a
simplified and specialized case even without multicast, and I would like to
think about that more.

We are also creating a separate mailing list, address@hidden, to
discuss these things.

Lars Nooden wrote:

> David Sugar wrote:
> > ...
> > I also added twinkle and the GNU zrtp stack to the archives because the
> > versions I found in both gNewSense and Trisquel were old and known broken
> > versions.  It had taken two years to get Debian to finally upgrade to
> > valid and working versions of those packages...
> One of the barriers to remove is difficulty in finding full contact
> addresses for calling between different SIP services.  It's actually
> quite difficult to find how to call someone from one service while using
> another.  e.g from Ekiga to SIP Skype.
> That is in part a documentation issue.
> If there's a chance to add to the wish list, then I would add a request
> for conference calling.  At least one-to-many multicast would be useful
> for a great many live performances like council meetings, lectures,
> conferences, and workshops.
> /Lars

reply via email to

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