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, gnucomm-priv...@gnu.org, 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 > _______________________________________________ gNewSense-dev mailing list gNewSense-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/gnewsense-dev