There are many solutions. Some more broken than others. Here's a quick summary of what I've found while looking for a base for a proper automated testing solution.
It's ok if you want only single dialog at a time. What doesn't work here is complex solutions where you need to synchronise 2 call legs, do registration, call and presence in the same scenario. If you go this way, you'll end up with running multiple sipp scenarios for each conversation element separately. Sipp also doesn't scale at all for media transfers. Even though it's multithreaded, something stops it from running concurrently - if you look at htop for example, you'll see that sipp never crosses the 100% line. Around 50 media calls it starts to cut audio and take all CPU of the machine.
It can sometimes lose track of what's happening, some packets which don't even belong to the call really, can fail the test. It's got some silly bugs like case-sensitive comparing of the headers.
Ruby-based solution where you have to write your own scenarios in Ruby. It's got its own SIP stack and lots of tests. While it's generally good and handles a lot of complex scenarios nicely, its design is terrible. Bugs are hard to track and after a week I had >10 patches that I needed just to make it do basic stuff. Later I learned that some of the scenarios are just written in a different way, but SIPr developers were not really responsive and it took a lot of time to find it out. Synchronising actions of many agents if a hard problem, since they'd rather use an event-based, but still single-threaded version... it just makes you concentrate too much on "what order can this happen in and do I handle it correctly", rather than writing the actual test.
Commercial solution. Never tested it properly since the basic functionality is missing from the evaluation version and it's hard to spend that much money on something you're not sure works...
Java-based solution reusing Jain-SIP stack. It can do almost any scenario and is fairly good. It tries to make everything non-blocking / action based leading to the same problems SIPr has, but in this case it's trivial to make it parallel / threaded. It has its own share of bugs, so not everything works well in the vanilla package, but most of the stuff is patchable. The developers seem to be busy with other projects, so it's not updated for a long time. If you need transfers, presence, dialog-info, custom messages, RTP handling, etc. - you'll have to write your own modifications to support them. It is not good for performance testing.
If you're a Java-hater like me, it can be used in a simple way from Jython, JRuby or any other JVM language.
In the end, I chose SIPunit as the least broken/evil/unusable solution. It is by no means perfect, but... it works in most cases. If I was doing the project once again with all this knowledge, I'd probably reuse SIPp configurations and try to write my own, sane solution that uses proper threading - but that's at least a ½ year project for one person, to make it good enough for production.
Check out SIPp at SourceForge. It has many different scenarios for testing which the UAS mode (server) would probably be interesting for you and seems to allow INVITE, BYE, etc.
Try SIPInspector. It is a JAVA based utility to re-create different SIP signaling scenarios. It can play RTP and stress test your system too. Since written in JAVA it is highly portable and works on different oeprating systems. Way easier to user than SIPp.
除了呼叫是否接通之外，您还想测试什么？您不能简单地从设备 A 呼叫设备 B 并查看是否可以通过连接进行通话吗？如果您想查看正在发送的数据包，您应该查看 wireshark。
What do you want to test apart from if the call gets through? Can't you simply call device B from device A and see if you can talk through the connection? If you want to have a look at the packets being sent you should look into wireshark.
发布评论
评论（4）
有很多解决方案。有些比其他更破碎。以下是我在寻找适当的自动化测试解决方案基础时发现的内容的快速摘要。
如果您一次只需要一个对话，也可以。这里不起作用的是复杂的解决方案，您需要同步 2 个呼叫线路，在同一场景中进行注册、呼叫和在线状态。如果您这样做，您最终将分别为每个对话元素运行多个 sipp 场景。 Sipp 也根本无法针对媒体传输进行扩展。尽管它是多线程的，但有些东西会阻止它同时运行 - 例如，如果您查看
htop，您会发现 sipp 永远不会跨越 100% 线。大约 50 个媒体通话后，它开始切断音频并占用机器的所有 CPU。有时它可能会忘记正在发生的事情，一些甚至不属于真正呼叫的数据包可能会导致测试失败。它有一些愚蠢的错误，例如区分大小写的标题比较。
基于 Ruby 的解决方案，您必须在 Ruby 中编写自己的场景。它有自己的 SIP 堆栈和大量测试。虽然它总体上很好并且可以很好地处理许多复杂的场景，但它的设计很糟糕。 Bug 很难追踪，一周后我有超过 10 个补丁，我需要这些补丁来让它做基本的事情。后来我了解到，有些场景只是用不同的方式编写的，但 SIPr 开发人员并没有真正响应，花了很多时间才找到它。同步许多代理的操作如果是一个难题，因为他们宁愿使用基于事件但仍然是单线程的版本......它只会让你过于关注“这会以什么顺序发生以及我要处理它”正确”，而不是编写实际的测试。
商业解决方案。从未正确测试过它，因为评估版本中缺少基本功能，并且很难花那么多钱在您不确定是否有效的东西上...
基于 Java 的解决方案，重用 Jain-SIP 堆栈。它几乎可以胜任任何场景，并且相当不错。它试图使所有内容都成为非阻塞/基于操作，从而导致 SIPr 具有相同的问题，但在这种情况下，使其并行/线程化是微不足道的。它有自己的错误，所以并不是所有东西都能在普通包中正常运行，但大多数东西都是可以修补的。开发者好像忙于其他项目，所以很久没有更新了。如果您需要传输、状态、对话信息、自定义消息、RTP 处理等 - 您必须编写自己的修改来支持它们。这不利于性能测试。
如果您像我一样讨厌 Java，那么可以通过 Jython、JRuby 或任何其他 JVM 语言以简单的方式使用它。
最后，我选择 SIPunit 作为最不损坏/邪恶/不可用的解决方案。它绝不是完美的，但是......它在大多数情况下都有效。如果我用所有这些知识再次进行该项目，我可能会重用 SIPp 配置并尝试编写自己的、使用正确线程的理智解决方案 - 但这对于一个人来说至少是一个 1/2 年的项目，以使其变得更好足够生产。
There are many solutions. Some more broken than others. Here's a quick summary of what I've found while looking for a base for a proper automated testing solution.
It's ok if you want only single dialog at a time. What doesn't work here is complex solutions where you need to synchronise 2 call legs, do registration, call and presence in the same scenario. If you go this way, you'll end up with running multiple sipp scenarios for each conversation element separately. Sipp also doesn't scale at all for media transfers. Even though it's multithreaded, something stops it from running concurrently - if you look at
htopfor example, you'll see that sipp never crosses the 100% line. Around 50 media calls it starts to cut audio and take all CPU of the machine.It can sometimes lose track of what's happening, some packets which don't even belong to the call really, can fail the test. It's got some silly bugs like case-sensitive comparing of the headers.
Ruby-based solution where you have to write your own scenarios in Ruby. It's got its own SIP stack and lots of tests. While it's generally good and handles a lot of complex scenarios nicely, its design is terrible. Bugs are hard to track and after a week I had >10 patches that I needed just to make it do basic stuff. Later I learned that some of the scenarios are just written in a different way, but SIPr developers were not really responsive and it took a lot of time to find it out. Synchronising actions of many agents if a hard problem, since they'd rather use an event-based, but still single-threaded version... it just makes you concentrate too much on "what order can this happen in and do I handle it correctly", rather than writing the actual test.
Commercial solution. Never tested it properly since the basic functionality is missing from the evaluation version and it's hard to spend that much money on something you're not sure works...
Java-based solution reusing Jain-SIP stack. It can do almost any scenario and is fairly good. It tries to make everything non-blocking / action based leading to the same problems SIPr has, but in this case it's trivial to make it parallel / threaded. It has its own share of bugs, so not everything works well in the vanilla package, but most of the stuff is patchable. The developers seem to be busy with other projects, so it's not updated for a long time. If you need transfers, presence, dialog-info, custom messages, RTP handling, etc. - you'll have to write your own modifications to support them. It is not good for performance testing.
If you're a Java-hater like me, it can be used in a simple way from Jython, JRuby or any other JVM language.
In the end, I chose SIPunit as the least broken/evil/unusable solution. It is by no means perfect, but... it works in most cases. If I was doing the project once again with all this knowledge, I'd probably reuse SIPp configurations and try to write my own, sane solution that uses proper threading - but that's at least a ½ year project for one person, to make it good enough for production.
查看 SourceForge 上的 SIPp。它有许多不同的测试场景，其中 UAS 模式（服务器）可能会让您感兴趣，并且似乎允许 INVITE、BYE 等。
Check out SIPp at SourceForge. It has many different scenarios for testing which the UAS mode (server) would probably be interesting for you and seems to allow INVITE, BYE, etc.
尝试 SIPInspector。它是一个基于 JAVA 的实用程序，用于重新创建不同的 SIP 信令场景。它也可以播放 RTP 并对您的系统进行压力测试。由于它是用 JAVA 编写的，因此具有高度的可移植性，并且可以在不同的操作系统上运行。比 SIPp 更容易使用。
Try SIPInspector. It is a JAVA based utility to re-create different SIP signaling scenarios. It can play RTP and stress test your system too. Since written in JAVA it is highly portable and works on different oeprating systems. Way easier to user than SIPp.
除了呼叫是否接通之外，您还想测试什么？您不能简单地从设备 A 呼叫设备 B 并查看是否可以通过连接进行通话吗？如果您想查看正在发送的数据包，您应该查看 wireshark。
What do you want to test apart from if the call gets through? Can't you simply call device B from device A and see if you can talk through the connection? If you want to have a look at the packets being sent you should look into wireshark.