如何设计电信级SIP服务器？

有一些SIP服务器可以处理几千个订户，还有一些可以处理数百万个具有类似底层硬件的订户。要实现能够处理如此大量流量的SIP服务器，需要考虑哪些设计和开发因素

首先，我假设您对构建自己的SIP信令应用程序感兴趣，因此您的问题是针对SIP应用程序服务器以及在其上运行的应用程序。我不会谈论像星号这样的产品。对于包含SIPServlet容器的Java应用服务器，没有太多的选择。基本上，三大巨头是IBM的WebSphere server、Oracle的Communications server和Mobicents。我对WebSphere非常熟悉，您可以在www.wasdev.net上免费下载WebSphere，但我相信所有这些产品在信令方面都可以很好地扩展。远远超过了几千个端点，如果您愿意集群服务器，您可以非常轻松地支持每秒数千个呼叫。这就是像AT&T这样的一级提供商将其Voip服务扩展到大量端点的方式

如果您的问题中包含媒体处理，那么您很快就会开始遇到可伸缩性问题。服务器端媒体处理（录制/播放、多路混音、SFU等）可能是处理器密集型的。在sipservlet世界中，媒体服务器通过媒体控制API（jsr309）进行控制，该API描绘了来自媒体平面的信令平面。因此，在不了解SIP服务器需要承载的应用程序类型的情况下，很难回答您的问题

有很多因素会影响依赖SIPservlet容器的SIPservlet应用程序的可伸缩性。线程是关键。您希望确保在应用程序代码中从不阻塞线程。一切都必须是异步的才能扩展。对于不习惯编写异步代码的开发人员来说，这可能需要一点时间来适应，但在进行任何实时信号开发之前弄清楚这一点是至关重要的。就Java服务器而言，您还希望调整JVM以获得最佳结果。这超出了确保有足够的堆空间来容纳服务器必须支持的每秒调用数的范围。有许多JVM垃圾收集（GC）旋钮可以用来调整托儿所大小等。GC配置是否适合您的服务器至关重要。大多数JVM还具有特定的GC算法，这些算法被设计为更好地用于实时应用程序。例如，ibmwebsphere使用的JVM支持一种称为metronome的GC算法，该算法用GC活动来换取低延迟

这是一个巨大的主题，因此如果您能提供更多关于您尝试使用SIP服务器实现的细节，我可能能够提供更多的见解

从纯标准的角度来看，SIP服务器处理SIP流量的目的是路由（查找用户或其他服务器），而不是其他。我假设这里我们讨论的是SIP代理服务器

传入请求在SIP服务器上使用有状态或无状态模式进行处理

您可以从rfc3261中获得这两个的定义：

  Stateful Proxy: A logical entity that maintains the client and
     server transaction state machines defined by this specification
     during the processing of a request, also known as a transaction
     stateful proxy.  The behavior of a stateful proxy is further
     defined in Section 16.  A (transaction) stateful proxy is not
     the same as a call stateful proxy.

  Stateless Proxy: A logical entity that does not maintain the
     client or server transaction state machines defined in this
     specification when it processes requests.  A stateless proxy
     forwards every request it receives downstream and every
     response it receives upstream.

到达有状态代理服务器的传入SIP请求通常会存在很短的时间。这段时间通常很短。例如，路由BYE需要分配两个事务：一个传入事务和一个传出事务。它将存在于内存中，直到达到rfc3261图6和图8所述的“终止”状态。对于TCP，定时器J和定时器K为0秒，因此，理论持续时间比接收答案的时间稍长。对于UDP，计时器J为32秒，因此，分配的事务上下文必须在收到最后一个应答后至少32秒存在（以处理重传）

为了优化内存并加快速度，可以使用无状态处理。然而，这意味着重传将需要进行新的计算，以找出与第一次处理完全相同的结果。在高损耗或低流量情况下，与有状态模式相比，这会增加CPU使用率。无状态模式还要求始终处理完全相同的请求，通常用于拒绝不需要的/中断的流量：这可能有助于抵御DDOS攻击、拒绝有语法问题的消息或拒绝禁止的流量

当然，下一个问题是关于实现的：您需要使用好的操作系统、好的线程、好的异步非阻塞DNS或套接字操作、关心内存使用、分配等

您报告说存在处理数千个订阅者和其他数百万订阅者的服务器：事实上，没有理由一个真正的代理SIP服务器不能处理数百万个订阅者（当然，如果编码正确的话）。处理“仅”几千个订阅者的服务器通常充当端点（如星号）：它们根本不是rfc3261中描述的SIP服务器，即：SIP代理服务器

作为旁注，即使是真正的代理服务器通常也能够欺骗和插入媒体中继：处理RTP中继。虽然现在需要处理媒体建立（如果您没有ICE），但这在带宽方面引入了一个严重的限制：95%的流量将变成RTP而不是SIP，并且带宽将是服务器的限制

当然，查看与ser相关的项目（ser、kamailio、opensips…）将展示上述所有内容：

• 它们可以在有状态模式下处理事务
• 它们可以在无状态模式下处理事务
• 它们可以配置为仅执行路由
• 如果以这种方式配置，他们可以处理大量订阅者
• 如果您激活一些东西（rtp中继、呼叫控制、状态…），服务器将