关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。
想改进这个问题？将问题更新为 on-topic对于堆栈溢出。
8年前关闭。
Improve this question
我正在寻找一个测试工具SIP来电。从 SIP 设备 A 向 SIP 设备 B 发起调用并报告结果的平台...
任何的想法？一个模拟平台将是理想的。
谢谢，
类别
最佳答案
有很多解决方案。有些人比其他人更 splinter 。这是我在寻找合适的自动化测试解决方案基础时发现的内容的快速摘要。
如果您一次只想要一个对话框，那没关系。在这里不起作用的是复杂的解决方案，您需要在同一场景中同步 2 个调用分支、注册、调用和在线状态。如果你这样做，你最终会为每个对话元素分别运行多个 sipp 场景。 Sipp 也根本无法扩展媒体传输。尽管它是多线程的，但有些东西会阻止它同时运行——如果你查看
htop例如，您会看到 sipp 永远不会越过 100% 线。大约 50 个媒体调用它开始切断音频并占用机器的所有 CPU。它有时会忘记正在发生的事情，一些甚至不属于调用的数据包可能无法通过测试。它有一些愚蠢的错误，例如标题的区分大小写比较。
基于 Ruby 的解决方案，您必须在其中使用 Ruby 编写自己的场景。它有自己的 SIP 堆栈和大量测试。虽然它通常很好并且很好地处理了许多复杂的场景，但它的设计很糟糕。错误很难跟踪，一周后我有超过 10 个补丁，我只需要让它做一些基本的事情。后来我才知道，有些场景只是用不同的方式编写的，但是 SIPr 开发人员并没有真正响应，花了很多时间才找到它。如果遇到难题，同步许多代理的操作，因为他们宁愿使用基于事件但仍然是单线程的版本......它只会让你过多地关注“这会发生什么顺序，我会处理它正确”，而不是编写实际的测试。
商业解决方案。从未正确测试过它，因为评估版缺少基本功能，而且很难在你不确定的东西上花那么多钱......
重用 Jain-SIP 堆栈的基于 Java 的解决方案。它几乎可以完成任何场景并且相当不错。它试图使所有内容都基于非阻塞/基于 Action ，从而导致 SIPr 具有相同的问题，但在这种情况下，使其并行/线程化是微不足道的。它有自己的错误份额，因此并非所有东西都在 vanilla 包中运行良好，但大多数东西都是可修补的。开发者似乎在忙其他项目，所以很久没有更新了。如果您需要传输、状态、对话信息、自定义消息、RTP 处理等 - 您必须编写自己的修改来支持它们。它不适合性能测试。
如果您像我一样讨厌 Java，可以通过 Jython、JRuby 或任何其他 JVM 语言以简单的方式使用它。
最后，我选择了 SIPunit 作为最不损坏/邪恶/不可用的解决方案。它绝不是完美的，但是......它在大多数情况下都有效。如果我用所有这些知识再次做这个项目，我可能会重用 SIPp 配置并尝试编写我自己的、使用适当线程的、理智的解决方案——但对于一个人来说，这至少需要 ½ 年的项目，才能让它变得更好足以生产。
关于simulator - SIP测试平台，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2380148/