答案 0 :(得分：27)
有很多解决方案。比其他人更破碎。以下是我在寻找合适的自动化测试解决方案基础时所发现的内容的快速摘要。
如果您一次只想要一个对话框，那就没关系。这里不起作用的是复杂的解决方案，您需要同步2个呼叫支路，在同一场景中进行注册，呼叫和在线状态。如果你这样做，你最终会分别为每个会话元素运行多个sipp场景。 Sipp也根本不进行媒体转移。即使它是多线程的，也会阻止它同时运行 - 例如，如果你看htop，你会发现sipp从未超过100％线。大约50个媒体呼叫它开始削减音频并占用机器的所有CPU。
它有时可能会丢失正在发生的事情，一些甚至不属于该呼叫的数据包可能无法通过测试。它有一些愚蠢的错误，比如对标题进行区分大小写的比较。
基于Ruby的解决方案，您必须在Ruby中编写自己的场景。它有自己的SIP堆栈和大量测试。虽然它通常很好并且可以很好地处理许多复杂的场景，但它的设计非常糟糕。臭虫很难跟踪，一周之后，我需要10个补丁才能让它做基本的东西。后来我了解到一些场景只是以不同的方式编写，但SIPr开发人员并没有真正的响应，而且花了很多时间才找到它。如果出现问题，请同步许多代理的操作，因为他们宁愿使用基于事件但仍然是单线程的版本...它只会让您过分关注“这种情况会发生什么样的情况并且我会处理它正确“，而不是写实际的测试。
商业解决方案。由于评估版本缺少基本功能，因此从未对其进
基于Java的解决方案重用Jain-SIP堆栈。它几乎可以用于任何场景并且相当不错。它试图使所有基于非阻塞/动作的行为导致SIPr具有相同的问题，但在这种情况下，使其并行/线程是微不足道的。它有自己的错误份额，所以并不是所有东西都能在vanilla包中运行良好，但大多数东西都是可修补的。开发人员似乎忙于其他项目，因此很长时间没有更新。如果您需要传输，状态，对话信息，自定义消息，RTP处理等 - 您必须编写自己的修改以支持它们。这对性能测试不利。
如果你是像我这样的Java-hater，它可以从Jython，JRuby或任何其他JVM语言以简单的方式使用。
最后，我选择SIPunit作为最少破坏/邪恶/无法使用的解决方案。它绝不是完美的，但......在大多数情况下都适用。如果我再次使用所有这些知识进行项目，我可能会重用SIPp配置并尝试编写我自己的，使用正确线程的理智解决方案 - 但这对于一个人来说至少是一年半的项目，以使其变得更好足以生产。
答案 1 :(得分：9)
在SourceForge上查看SIPp。它有许多不同的测试方案，UAS模式（服务器）可能会对你感兴趣，并且似乎允许INVITE，BYE等。
答案 2 :(得分：2)
试试SIPInspector。它是一个基于JAVA的实用程序，用于重新创建不同的SIP信令方案。它也可以播放RTP并对您的系统进行压力测试。自从用JAVA编写以来，它具有高度的便携性，适用于不同的操作系统。用户比SIPp更容易。
答案 3 :(得分：-2)
除了电话是否通过之外，你想测试什么？你不能简单地从设备A呼叫设备B，看看你是否可以通过连接进行通话？如果您想查看正在发送的数据包，请查看wireshark。