Microsoft 终止与 Asterisk 的合作关系——有哪些开源的 Skype 替代方案?

还没有读者喜欢这篇文章。
Different cell phones

Opensource.com

微软已经终止了其允许开源 Asterisk PBX 系统与 Skype 协同工作的协议,截止日期为 7 月 26 日,这可能是由于其自身竞争服务的推出

当微软在两周前以 85 亿美元收购 Skype 时,他们承诺将其作为一个独立的部门保留,并继续支持非微软平台,但用户对此持怀疑态度。 转变的苗头很快就出现了。 也许有人应该要求他们拉钩起誓。

开源用户应该转向哪里呢? 本周早些时候,GNU 项目宣布了GNU Free Call 作为开源替代方案,甚至在项目的使命中点名批评了 Skype

我们的目标是使 GNU Free Call 像 Skype 一样普及,并在可用性方面达到相似的水平,即在所有平台上可用,并可供公众直接用于已知和匿名方之间的各种安全通信,但无需向中心服务提供商注册,无需使用可能存在后门的不安全源代码秘密二进制协议,并且不具有任何可能被外部方利用或滥用的网络控制点。 通过将其作为一个自组织网状呼叫网络来实现,我们进一步消除了潜在的服务控制点,例如通过显式路由对等方,即使网络在民事紧急情况下被隔离。

我们确实认识到这个项目具有重大的长期社会和政治影响。 它还可能在公共服务中提供重要的实用性,通过支持在不需要现有通信基础设施的情况下继续提供紧急服务。 有许多常见的公共服务用途,例如电子健康服务的交付,以及医疗和法律通信,在这些领域,必须平等地对待所有人,维护隐私,而不论种族、宗教或政治派别。 同样重要的是,即使现有基础设施不再可用或已被蓄意禁用,也要继续提供紧急医疗服务。

但是 GNU Free Call 是未来,而不是你今天可以使用的东西。 即使 Skype 本身从未完全开源,越来越多的开源爱好者似乎也在寻找现成的、不在微软保护伞下的替代方案。

这些是我在各种留言板和博客文章中看到的建议。 我还没有听说过任何像 Skype 那样用户友好且即时可用的替代方案。 但我也没有使用过这些方案中的任何一个,因此我很想听听您对以下任何方案或您喜欢的其他方案的看法。

  • Ekiga:前身为 GnomeMeeting
  • Blink:VoiP 呼叫、视频和聊天 
  • Jitsi:还支持 XMPP、AIM 和其他 IM 服务
  • SylkServer:SIP 服务器和会议
  • SFLphone:适用于桌面和嵌入式系统的企业级软电话
  • Linphone:VOIP 客户端,也适用于 Android、Blackberry 和 iPhone
User profile image.
Ruth Suehle 是红帽开源和标准团队的社区领导经理。 她是《Raspberry Pi Hacks》(O'Reilly,2013 年 12 月)的合著者,也是 GeekMom 的高级编辑,GeekMom 是一个为那些在极客和育儿中找到乐趣的人提供的网站。

22 条评论

看来我要转向 Blink 了...

这也在一个邮件列表中被提及:Skype 是一个网络、一个客户端和一个协议。 没有什么全球消费者可用的东西可以与其易用性、覆盖范围和“即用即走”(大多数时候)相媲美,因为没有其他人提供完整的堆栈。 您上面列出的项目仅仅是客户端,它们需要一个网络(Ekiga 提供服务,但不可靠)。

GNU Freecall 可能会流行起来,也可能不会——它还有很长的路要走。

我怀疑一个或多个基于移动电话的服务可以将其覆盖范围扩展到其他设备; 像 Fring 这样的服务为手机和平板电脑提供了网络和客户端。 随着智能手机的普及,移动设备上已经有了 Skype 的可行替代方案,并且消费者已经熟悉它们,因此很容易迁移。

尽管如此,我怀疑微软终止 Asterisk 集成是否会对普通消费者产生影响。

要成为 Skype 杀手,该服务必须提供

1. 出色的质量。 基于互联网的 SIP 无法与 Skype 的质量相媲美。

2. 出色的跨平台支持,并且应用程序必须非常易于安装和配置。 诚然,Linux 上的 Skype 远不如所有其他 Skype 客户端。

3. 非常简单的电话会议设置。

4. 人们越来越多地将 Skype 用于屏幕共享等目的,这也非常容易设置。

5. 没那么重要,但 Skype 聊天是一个非常好的聊天系统。

6. 视频支持将变得越来越重要。

不幸的是,您列表中的任何一个都无法接近甚至与 Skype 的语音质量相媲美。 但我期待着有一天会出现一个开源的替代方案,能够提供以上所有功能。

您提出的观点中,只有第 2 点反映了现实。 但我将逐一解答。

1. SIP 具有多种编解码器选项,质量(和带宽使用)各不相同。 许多开放编解码器的质量比 Skype 好得多,许多则更差。 当我通过 Ekiga 和 SIP 呼叫服务 (diamondcard.us) 给他们拨打固定电话时,我收到了 Skype 用户的评论,例如“哇!您的声音真清晰!”。 您在语音质量方面的不佳体验与 Skype 与 SIP 无关,而与两个端点支持的编解码器有关。 当然,Skype 有自己的专有编解码器,它还不错,但绝不是最好的(无论是带宽还是质量)。

2. SIP 的最大问题是 NAT。 如果 SIP 不使用多个端口并且不必处理 NAT,那么 SIP *会* 非常容易设置。 (SIP 客户端已经跨平台且易于安装。) 我看到 Ekiga 论坛上数百名首次用户因令人沮丧的 NAT 问题而被拒之门外,我感到畏缩。 解决此问题的方法是
a) VPN。 我通过我设置的专用 VPN(openvpn)将 SIP 与家人和朋友一起使用。 Windows 也有优秀的 VPN 程序(包括 openvpn)。 这绕过了 VPN 上用户的 NAT 问题。

b) IPv6。 当两端都有 IPv6 地址时,不存在 NAT 问题。

c) IAX - Inter Asterisk eXchange 协议 - 这将 SIP 和 RTP/sRTP 使用的多个端口多路复用到一个 UDP 端口中,从而轻松穿越 NAT。 目前只有少数客户端支持此协议(Ekiga 不支持)。

d) sip 代理 - 技术娴熟的人员可以在其网关 Linux 服务器上运行 sip 代理。 这实际上为通过单个网关 IP 的多个并发 SIP 呼叫提供智能协议感知 NAT。 技术不太娴熟的人员可以购买类似路由器的盒子(个人 PBX),价格为 500 美元 - 1000 美元,为内部智能手机提供 sip 代理,并为中继线和 POTS 扩展提供一些电信端口。 (该盒子包含嵌入式 Asterisk 或同等产品。)

3. 使用众多免费 SIP 会议服务之一就像拨打相同的房间号一样简单。

4. SIP *不* 支持屏幕共享,也不应该支持——有很多很好的方法可以进行屏幕共享。 将其与 Skype 捆绑在一起只会加剧 Skype 带来的安全风险——您正在向互联网上所有机器上的所有其他 Skype 程序授予相当于 ssh 访问您机器的权限。 任何“破解”Skype 二进制文件的人都可以自由访问所有使用 Skype 的机器。 (在这种情况下,我真诚地希望 Skype 真的很难破解...)

5. SIP 也是一个非常好的聊天系统

6. 视频效果也很棒。

我想知道为什么在我迄今为止阅读的所有内容中,每个人似乎都将 SIP 视为 Skype 的候选替代方案。 我理解 SIP 已经与 VOIP 关联了相当长一段时间了。

但我认为另一个值得研究的新秀是:XMPP。 大多数人只将 XMPP 与即时消息联系起来,但该协议也向语音和视频开放,使用 jingle 标准。

并且 XMPP 确实有一个网络:Google Talk 基于 XMPP,Ovi Talk、Jabber 和许多独立的 xmpp 提供商也是如此。 好处是所有这些提供商都可以相互连接。 因此,Jabber 用户可以与 Google Talk 用户通信。 我认为这是 XMPP 优于 Skype 的一大优势。 虽然 Skype 在普及度方面领先一步,但它仅限于 Skype 用户。 另一方面,一旦您连接到 XMPP 网络,您就会突然连接到全球所有其他(公共)XMPP 网络。 避免供应商锁定的一个绝妙功能。 我不知道 SIP 在这方面的能力。 我知道它也具有互连功能,但我不知道它们是否像 XMPP 的那样强大。

在我听到 Skype 收购的消息后,我四处寻找并安装了带有 jabber 帐户的 Jitsi。 到目前为止,我只有有限的经验,但在我看来,它似乎确实具有使 Skype 如此流行的许多功能
<li>音频/视频通话</li>
<li>电话会议</li>
<li>即时消息</li>
<li>文件传输</li>
<li>屏幕共享</li>

它可以通过 SIP 或 XMPP 执行此操作。 此外,它还支持一些我不太感兴趣的其他 IM 协议。

我不会对音频/视频质量做出任何声明,但我最初的初步测试似乎并未表明它们会比 Skype 差。

我正在试验每夜构建版本。 您的里程数可能会因旧版本而异。 它确实还有一些粗糙的地方,但这对于 Beta 版本来说是可以预期的。

我最大的障碍可能是让我的 Windows 联系人理解我将来可能无法再使用 Skype,并让他们尝试另一个网络和 Jitsi 客户端。

总的来说,我觉得 SIP 和 XMPP 都蕴藏着巨大的潜力,可以成为继 Skype 之后强大的通信网络的基础,甚至在未来取代它。

现在阻止这种情况发生的可能不是协议,而是不同客户端之间的成熟度和互操作性。 我的经验是 Jitsi 到 Jitsi 工作正常。 但我无法让 Empathy 通过 SIP 或 XMPP 与 Jitsi 可靠地通信,而两者都声称完全支持这些协议。 也许这只是一个配置问题。 也许他们未能协商一个通用的音频或视频编解码器。 对于普通用户来说,消息是:它不起作用,这真的无关紧要。 这很糟糕。

我真的希望所有这些不同客户端的作者都能看到这里的机会,并共同努力解决这些问题。

在此之前,我将不得不混合使用 a. Skype,它可能会在 Linux 上越来越落后,以及 b. 与我的其他联系人达成一致,使用相同的替代方案。 哪一个尚未完全决定,但到目前为止,Jitsi 涵盖了我大部分必需的和锦上添花的功能。

声明:我与 Jitsi 没有任何关联。 我只是最近发现了它,尝试了一下,到目前为止很喜欢它。

让我们转向 Blink

听着。 对于想要像 skype 这样服务的人来说,我认为没有替代方案,我也不认为将来会有替代方案。 这有点像说 Mac 或 Linux 将超越 Windows。 虽然我喜欢开源,但我认为它将永远是小弟。 话虽如此,有很多服务可以为您提供更好的价格,并且它们会为您提供一些流行的免费客户端的逐步说明。 我不会在此处列出任何公司,因为担心我的帖子会被删除,但我使用免费客户端。 我每月支付 0.99 美元的美国号码费用,以及每分钟 0.009 美元的美国电话费用。 对于那些注重质量的人来说,您可以获得具有多种不同编解码器的 sip。 就价格而言,skype 每分钟 0.023 美元,以及 3 个月的来电号码费用 18 美元。 非常便宜,甚至还有免费的方法。

在人们对我发起攻击之前,我想补充一些内容。 开源更好,功能更强大,但它就是不如专有软件那么流行。 无论是易用性还是广告宣传,或者只是人们的舒适度,它都没有像专有表亲那样被广泛使用。

您的软电话是开源还是专有软件真的无关紧要——这只是个人选择。 有许多优秀的商业 SIP 软电话,以及开源软电话。 购买硬件——SIP 电话或个人 PBX 时,这一点甚至更不重要。 当协议是秘密和专有的时,这一点才 *确实* 重要。 这就是 Skype 的问题。 选择 Skype 服务会将您锁定在使用他们的客户端(反之亦然)。

我没有看到提及 Skype 的一项关键功能是能够拨打传统电话号码。 我认为这项服务对于与 Asterisk 一起使用至关重要。 更重要的是,虽然您可以使用开源工具拨打传统电话号码,但您始终需要某种形式的服务才能使其工作。

我正在关注 Google Voice 作为这方面的替代方案。 我想我读到您可以将电话号码移植到他们的服务,并且在某个时候,我找到了一个将其连接到 Asterisk 的教程。 我没有尝试过,但我很想听听其他尝试过的人的反馈。

有数百种(付费)服务提供 SIP 到 POTS,可与任何 SIP 客户端配合使用。 我不会提及名称,只需谷歌搜索“sip callout”即可。 这是开放协议的一大优势——选择服务不会将您锁定在客户端中。 (请参阅上面关于 XMPP 的帖子——这听起来像是 SIP 的一个有趣的替代方案。)

关于 Google Voice:它仅限于美国客户,并且不支持与 Asterisk 或其他电话软件一起使用。
这两者都可以克服,但 Joe OrdinaryUser 无法做到,并且 Google 可以随时破坏这些解决方法。
因此,即使我是 Google 粉丝,这也使 Google Voice 不符合 Skype 替代方案的条件。

Google Voice 可以在任何地方使用。 我使用 Skype 和 Google Voice 拨打手机或座机。 使用 Google Voice 拨打电话号码比 Skype 便宜,例如,在越南拨打手机的费用便宜 3 倍,但质量目前不如 Skype。

oovoo 作为 skype 替代品。

http://www.oovoo.com/home.aspx

XMPP 的 Jingle 协议——它是 Google 的 V/VOIP 服务的演进——正在变得非常接近。

Skype 实际上并没有什么神奇之处,它只是一个相当简洁的语音网络实现,而 XMPP 提供了去中心化和开放性,使其像电子邮件一样实用和明智地部署。

也有关于 Jingle 的 SIP 网关——SIP 和 Jingle 在设计上非常相似——并且也有 POTS 呼叫可用。

还有许多客户端——上面提到的 Jitsi 是其中之一,但 Empathy(通常与 GNOME 一起发布)、Psi 和 Gajim 也都在不同程度上支持 Jingle。

当前的障碍实际上不是网络的实现——甚至不是 NAT 问题,因为 STUN 在很大程度上解决了这个问题,即使我们不走 Jingle Nodes 路线——而是缺少“标准”编解码器的明显候选者。 这意味着您可以在地图上进行呼叫,但您并不总是可以发送实际的声音。

我有点困惑为什么 GNU 项目再次试图将我们推向单一实现的道路——真的,好处来自于拥有可靠的开放标准和互操作性,而不是单一的工作实现。 在 XMPP 世界中,我们有多种实现,因此您可以选择您喜欢的任何一种。 (请注意,我上面只提到了开源的实现,除了 Google 的实现)。

GNU 并没有试图推动单一实现。 他们正在推动一个开放协议——SIP,并且获得市场份额至少需要一个引人注目的实现。 XMPP 听起来像是 SIP 的良好开放竞争——尤其是当它只使用一个端口时。 STUN 除非您位于单个简单的消费级路由器后面,否则 *不能* 解决 NAT 问题。 在许多方面,它使情况变得更糟,因为它试图绘制出整个路由。 如果 SIP 代理更容易让非 SIP 专家配置,那么它们将解决 NAT 问题。 (嵌入式 PBX 解决方案通常很容易做到这一点。)

我读了一些关于 Jingle 的资料。 它仍然使用 RTP 来传输实际的语音/视频,因此它具有与 SIP 完全相同的 NAT 问题(STUN 无法解决,除非在非常简单的情况下)。 我知道的唯一完全解决 NAT 问题的开放协议(IPv6 除外)是 IAX——其中 SIP 和 RTP 封装在一个 UDP 端口中。

实际上,IAX2(标准的“官方”名称)不是 SIP,也不是 RTP。 它有自己的 RFC 5456。 它是信号和媒体在同一数据包流中的组合,对于客户端到客户端系统来说,它实际上非常好。 但是,它并不能解决 NAT 问题。 如果两端都在 NAT 后面,则仍然需要中间系统。

请注意,Skype 也存在同样的问题; 没有灵丹妙药。 但是 Skype 会“寄生”在具有公共 IP 地址的主机的带宽上,使用不知情的客户端“A”作为客户端“B”和“C”想要通话的中继点。 这就是它的扩展方式。 IAX2 和 SIP 在协议中没有关于端点如何找到愿意提供媒体中继的概念,尽管如果有人在更高的层编写了一个合适的智能包装器,他们就可以制作出这样的客户端。 但这很复杂,而 IAX2 和 SIP 等较低层的东西的程序员往往会在讨论转向更大规模和更高层的问题时尖叫着逃跑。 “把这个问题留给公司去解决”是他们的回答。

因此,Skype 是唯一一家在餐桌上的公司,他们(明智地)决定在构建系统时忽略所有标准。

JT

“但是,它并不能解决 NAT 问题。 如果两端都在 NAT 后面,则仍然需要中间系统。”

当然,但中间媒介不需要中继 RTP 数据包。 一旦两端都知道彼此的公共 IP 和端口,它们都会相互发送 UDP 数据包,并且两个 NAT 防火墙都会打开(单个)UDP 端口。 一些 SIP 客户端足够聪明,可以为每个 RTP 通道执行此操作(对传入和传出的多媒体数据使用相同的端口)。 但将所有内容都放在一个 UDP 端口中会使事情变得简单得多。

请查看 Jingle Nodes; 它是一种中继协议,允许客户端充当其联系人(仅限)的中继,如果他们愿意,也可以支持公共媒体中继。

当然,XMPP 不需要管理信令中继,因为它已经拥有现有的 XMPP 服务器联邦来充当巨大的信令中继。 而 Jingle Nodes 允许使用这个现有框架来查找由您的服务器或您的联系人提供的媒体中继服务。

真的,如果您已经拥有联系人、服务器和服务发现,那么媒体中继发现并不是一个很难解决的问题。

我使用 Ekiga 的运气不错,尽管您确实必须向运营商付费才能与人交谈。 Linux 上的 Skype 完全没用——它在功能上远远落后于 Windows 客户端,而且经常只是无法工作。

<em><strong>电信领域真的没有免费的午餐。</strong></em> 它是核心企业 IT 能力,应该使用与采购数据库、ERP 系统、内容管理系统或车辆相同的业务流程进行购买/租赁。 竞争性采购是一个时代已经到来并且经受了时间考验的想法。

没有人提到 sipXecs? - 它是一个开源 UC 替代方案,应该用于基于 SIP 和 XMPP 的通信,它允许与 Google Talk、CallManager presence & IM 以及许多基于 Jabber 的系统进行原生联邦。
易于下载和使用,即插即用....http://www.sipfoundry.org/home

Creative Commons License本作品采用知识共享署名-相同方式共享 3.0 未本地化版本许可协议进行许可。
© . All rights reserved.