我们目前正在为大约70个用户查看VoIP。 我们对运行“融合”networking（VoIP运行在与数据相同的电缆和交换机上）和“单独”（单独的电缆和交换机用于数据和VoIPstream量）的select有些混淆。 我们理解需要使用适当的设备，以便我们可以pipe理QoS，VLAN，必要时提供PoE等，尽pipe可以公平地说我们不了解相关细节或含义。
我们自己没有这样做，我们只是想对供应商的build议进行尽职调查。 当然，我们有不同的供应商的不同的build议。 供应商告诉我们为什么他们认为他们的build议更好，但我们有一些困难，把它们放在一起，以便我们可以select什么是最适合我们的。
我们大多数用户通过“直接”以太网连接连接到networking。 大约15个用户位于由光纤提供的独立build筑物中，但它们最终在同一个networking上。 目前没有VLAN，但我们了解VLAN的好处，如果我们决定融合（它允许使用“分离”，而不需要物理上分开的交换机和电缆）。 我们大约15个用户是在全国各地的远程工作者，我们还有10个左右的公路战士。 我不知道是否重要，但所有的远程工作人员，大多数公路战士和一些“固定”工作人员都在docker服务，我们最终将有三分之二的docker服务人员。
我们目前关注的大部分问题都与两个因素有关：软电话和桌面带宽。 据我们所知，select使用大量的软电话需要我们处理各种融合问题，即使我们在单独的networking上有硬电话。 这是真的？ 将软电话保持在一个单独的networking上唯一明智的方法是为每个用户提供2个网卡吗？
就桌面带宽而言，我们的理解是，融合networking中的标准方法是将硬件电话连接到networking，然后将用户的计算机连接到电话。 目前我们为每个用户提供千兆比特，可以向计算机提供千兆比特的电话的成本远高于100兆比特，我们实际上运行单独的networking（假设大多数用户获得硬电话）实际上更便宜。
有一些事情我们已经知道了。 我们知道，在任何融合configuration中丢失交换机都会closures数据和语音，但是我们也知道，预先configuration的备用机器将使我们的停机时间维持在故障排除和定位失败所需的时间设备。 我们知道，我们必须做好networking融合的工作，而不仅仅是更换一些交换机（取代交换机并不是一个真正的问题，因为无论如何都是出于其他原因）。 我们已经看过这样的文章，它们对理解一般概念是有帮助的，但是对具体细节有一点点的了解。
更新1：我们没有运行一个呼叫中心。 根据我们的电话报告，我们没有10路线路的封锁电话。 这十条线路服务于我们总部的约50人。 我不记得在线的build议（我今天在家工作），但是肯定不需要增加行数。
更新2 – 查询：我没有看到任何人评论我们之间运行的两个build筑物之间的光纤链路的影响。 那是因为它对这个问题没有影响？ 在这种情况下甚至可以运行单独的networking吗？ 据我所知，我们是多模式的能力。
更新3 – 为什么我selectPLZ：每个回应都非常有用，但是最终，PLZ让我们考虑了一些我们还没有考虑过的事情。 我们已经了解了一些我们在这里学到的知识，从我们的供应商处获得更多信息 他们回来了，他们的build议更明确的理由，所以我认为我们现在会好起来的。 就目前来看，融合（与VLAN等）看起来最有可能考虑到我们目前的基础设施，呼叫量和软电话的偏好。
这很大程度上取决于您的电话系统将要使用的带宽 – 如果它是一个有数百人同时在电话上的呼叫中心，则您将需要一个单独的networking，而不是仅仅需要电话的几百个办公室在他们的办公桌上，但不是沉重的用户。 一个保守的（比“实际使用的方式”更多）估计是每个同时呼叫128kbps，或每兆位8个呼叫，所以gigE可以做大约8000个同时呼叫（好，由于开销less一点，但是这是正确的数量级）。 所以这不太可能是一个瓶颈。 只要你有QoS，以便大量下载不会影响你的手机stream量，你应该没问题。
PoE交换机的PoE交换机与非PoE交换机相比，其价格要高得多（可以购买和运行）。 PoE的一个很好的function是交换机上的单个UPS可以在停电期间保持所有的电话正常运行。
我过去所做的是：在每个人的办公桌上安装一个PoE和一个非PoE端口。 PoE被标记为“电话”，非PoE是“数据”。 这为用户的计算机保留了数据速度，为手机获得了前述的电源冗余，并允许我（最终，如果需要的话）更多地分离networking。
所以我想我说的是：不要打扰'软件'不收敛，但是在硬件问题的独立networking上打扰。 如果硬件将是相同的（即，您正在运行所有PoE或全非PoE交换机），那么融合networking应该没问题。
融合与非融合networking。 我个人会build议将VOIP和数据分离到单独的物理networking…非融合选项。 这样做的理由是，在我看来，成本差异并不是那么重要，它提供了一些优势。
第一个好处是，不pipe你的数据用户在做什么，都不会影响你的手机。 在带宽之间，感染病毒，物理故障和/或用户恶意的用户有很多可能的方式让数据用户在共享任何基础设施的情况下影响您的VOIP用户。 即使你正在应用QoS策略，如果你有一个用户爆破100Mbps的以太网stream量，它可以过载交换机处理器，build立一个环境以太网冲突很可能发生，等等。在我的脑海中，你运行第二套电缆，你扔第二套开关，你不必担心这一点…。
第二个原因是安全。 一个聪明的用户出去抓取VOIPstream量并重build他们本来不应该听的电话对话并不难。 是的，这可以通过使用单独的VLAN来在很大程度上得到缓解，但是有一些技术可以让您从一个VLAN跳到另一个VLAN ……在两个完全分开的物理networking上拥有stream量限制了这一点。 有两个独立的networking不会阻止这个，但在我看来，因为他们必须通过物理连接到第二个networking才能窥探，所以这个问题需要处理很多“他是否打算这么做？”的问题。
第三，在我看来，从故障排除的angular度来看，networking是非常好的。 如果你没有任何东西，但VOIP电话通过networking，那么你不必翻找Wireshark捕获寻找你想要的stream量的一页又一页。是的，这是什么查找或filter，但在我的观点VOIP是棘手的故障排除和尽可能简单，因为你可以保持你的问题排除故障，你会更好。
软电话将成为一个问题，并没有一个真正的好工作。 您应该能够捕获stream量并应用QoS策略来提高您的数据networking的可能性，但实际上，只有这么多，您才能做到。 我喜欢软电话，他们是整洁的小工具，但我不会推荐使用一个作为主要电话的人必须有一个可靠的电话。 我怀疑你可以拿出一些解决scheme，在每台使用软电话客户端的机器上安装2个网卡，但是这样做仍然不能保护你免受软电话呼叫中的猝死问题的困扰，因为PC的CPU正在啃开大文件。
我build议在决定实施软电话之前testing软电话，让供应商在机器上安装一个软件电话，然后锤击该机器上的CPU，看看质量是否会降低到您可以接受的程度。
我强烈build议不要使用一根电缆作为语音和数据，我知道这样做是可行的，但是由于这些电缆不是在单独的广播域上，所以如果PC传输很大，那么访问媒体的电话就会出现问题。
另一个我喜欢独立networking的次要原因是，如果你在某个networking上发生了某种灾难性的崩溃，那么你就有一个交换机被炸掉了……你有一个第二个networking，你知道可以工作有时会暂时投入使用，以便覆盖您，直到您获得其他networking的固定为止…我知道这有点违背了我之前的所有论点，但是如果让用户恢复正常运行，我可以违反自己的规则
关于我能想到的唯一的一个论点，就是融合networking与非融合networking的融合是一个易于pipe理的论证。 虽然我尽可能保持您的networking容易，但我不觉得额外的networking增加了networkingpipe理的复杂性。
国际海事组织，你需要考虑如何pipe理，以及如何将其整合到你的组织。 你有多个不同的pipe理团队，或一个团队？
文章往往是通用的，因为很多人的立场，他们坚持宗教般的热情，而不是基于事实。 没有人回答。
对于你的情况，这听起来像你在哲学上像terminal服务，并倾向于这个方向。 但与此同时，你也有携带笔记本电脑的勇士。 我认为这是一个很好的位置，因为你的terminal用户中有很大一部分是在terminal服务上，你可以很容易地模拟他们的带宽需求，build立一个有足够容量来满足你的需求的融合networking。
pjz的build议，拉动PoE和非PoE也非常有意义，因为它给你灵活的服务你的道路上的士兵和瘦客户端谁需要硬电话。