SIP 中继的普及使这些 SIP 中继的语音带宽计算成为 IT 组织必须解决的问题。带宽过大，就无法实现投资回报率，总体拥有成本也会高于必要水平。带宽太小会导致呼叫阻塞，呼叫者放弃呼叫，联络中心和服务台座席的工作效率降低。企业的服务声誉可能受到损害。
尺寸不合理的影响
SIP 中继连接的设计者必须考虑六点，以确保有效和高效的 SIP 中继连接：
- 过度设计浪费金钱
- 过度设计需要更多带宽，但这并不能提高性能
- 购买的 SIP 许可证多于所需，并且无法退还
- 设计不足会阻止通话，从而减少收入和利润
- 设计不足使客户失望
- 带宽设计不足影响通话质量
确定中继线容量
确定所需中继容量的过程首先要确定服务等级 (GoS)，即呼叫者在呼叫中心、企业办公室或任何其他用于接听电话（无论是语音还是交互式语音应答 (IVR) 电话）的位置听到忙音的概率。第一步使用 Erlang B 公式和计算。第二步是计算支持 Erlang 计算确定的 SIP 中继会话数量所需的带宽。在这种情况下，中继是承载呼叫所需的线路/会话数量。
Erlang B 计算
可以使用 Erlang B 计算来计算呼叫流量负载所需的中继线数量。还有其他几个公式，其假设略有不同，但 Erlang B 仍在电话行业中使用。
Erlang B 是一个可用于呼叫中心和服务台调度的公式。该公式假设未成功的呼叫（呼叫被阻止，呼叫者收到忙音）不会排队或重试；它将永远丢失。该公式还假设呼叫自上次呼叫以来独立且随机地到达。
Erlang B 倾向于低估所需的会话数量。Erlang B 扩展公式的变体可以解释 10% 到 70% 的呼叫者，如果他们的呼叫没有接通，他们会立即重试。扩展公式将产生承载呼叫负载所需的稍多的中继线数量。
如果您知道或可以预测其他两个因素，则可以使用公式（Erlang B 和扩展）来计算以下三个因素中的任意一个：
- 忙时流量 (BHT)：运营最繁忙时段的呼叫流量小时数，也称为 Erlang 负载。
- 阻塞（忙音服务等级 (GoS)）：由于可用线路不足而被阻塞的呼叫的百分比，例如 1%。
- 线路：中继组中的会话数。一个会话一次可以承载一个呼叫。
繁忙时段是一天中流量最大的时段。通过针对繁忙时段进行设计，呼叫者将以企业期望的速率遇到呼叫阻塞。一天中其他时段的流量将较少。这意味着呼叫者将遇到更少的阻塞呼叫（忙音），并在一天的其余时间获得更好的服务。最差情况性能（GoS）是在繁忙时段提供的。
这是如何使用 Erlang B 计算器。第一个决定更多的是业务问题：呼叫者听到忙音的频率是多少？大多数计算都以 .01（1% 忙音）的 GoS 开始，这意味着 99% 的呼叫得到应答并且没有收到忙音。.001 的 GoS 意味着 99.9% 的呼叫没有收到忙音。交互式语音应答 (IVR) 系统的设计应该具有非常高的呼叫不被阻塞的概率 – 即 99.9% 或更高。
接下来，必须以 Erlangs/BHT 为单位测量或估算流量负载。一个 Erlang 相当于一个会话/线路忙碌一小时。要计算 Erlang 负载，中继设计人员必须确定通话的平均时长（以分钟为单位）。一天中最繁忙时段的预期通话数量也是必要的。Erlang 负载 (BHT) = CAR XH/60。
在哪里：
- 呼叫到达率（CAR）是指繁忙时段到达的呼叫数量
- 平均通话时长或保持时间（H）以分钟为单位
计算示例：
CAR = 100 次呼叫，H = 3 分钟
此情况下的 Erlang 负载为 100×3/60 或 5.0 Erlangs (BHT)
这相当于 5 个会话 100% 的时间都在运行，这种情况会产生大量被阻止的呼叫。因此，会话数必须大于 5 才能提供更好的 GoS。现在已知 GoS 为 .01，Erlang 负载为 5，请前往Westbay Engineers ，在 BHT（Erlang 负载）中输入 5，在“阻塞”字段中输入 .01。结果是，此流量负载和 GoS 需要 11 个会话。这说明每个会话的运行繁忙度为 45%。如果同一网络的设计目标限制为 .001 GOS，即 99.9% 的呼叫不会被阻止，则需要 14 个会话，而不是 11 个会话。
VoIP 带宽计算
VoIP 会话所需的带宽取决于几个因素：压缩技术、数据包开销、使用的网络协议。
数据包大小、语音压缩选择和报头压缩的不同设计使得确定语音呼叫的带宽变得困难。大多数提供商选择 20ms 或 30ms 的语音作为有效负载大小。应要求 SIP 中继提供商为其服务提供类似上述表格，用于计算带宽要求。提供商的带宽要求可能更大。一个好的经验法则是，为 8Kpbs G.729 压缩语音，每个呼叫至少保留 27 Kbps 的 SIP 会话带宽。如果使用 G.711，则每个会话至少保留 83 Kbps 的带宽。一些提供商建议每个会话/呼叫 100 kbps。
设计人员不应在考虑最小容量的情况下计算所需的会话数。始终将会话数和带宽四舍五入为更大的数量。流量估算只是估算。增加带宽总比呼叫者不满意要好。试验语音质量以确保实施足够的带宽。
内容源自telecomreseller.
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/51689.html
