Испытательная платформа SIP

Ответ 1

Откажитесь от SIPp в SourceForge. У этого есть много различных сценариев для тестирования, который режим UAS (сервер), вероятно, был бы интересен для вас и, по-видимому, позволял INVITE, BYE и т.д.

Ответ 2

Существует много решений. Еще несколько сломанных, чем другие. Вот краткий обзор того, что я нашел, ища базу для правильного автоматического тестирования.

• SIPp

Это нормально, если вы хотите только один диалог за раз. Что здесь не работает, это сложные решения, в которых вам нужно синхронизировать 2 вызова, выполнять регистрацию, вызов и присутствие в том же сценарии. Если вы пройдете этот путь, вы в конечном итоге будете запускать несколько сценариев sipp для каждого элемента разговора отдельно. Sipp также не масштабируется для передачи мультимедиа. Несмотря на то, что он многопоточен, что-то мешает ему работать одновременно - если вы посмотрите на htop, например, вы увидите, что sipp никогда не пересекает линию 100%. Около 50 медиа-вызовов начинает обрезать аудио и принимать все процессоры машины.

Иногда он может потерять информацию о том, что происходит, некоторые пакеты, которые даже не относятся к вызову, могут вывести из строя тест. Он получил некоторые глупые ошибки, такие как сравнение заголовков с учетом регистра.

• SIPr/sipper

Решение на основе Ruby, где вам нужно написать свои собственные сценарии в Ruby. Он получил свой собственный стек SIP и множество тестов. Хотя он в целом хорош и хорошо справляется с множеством сложных сценариев, его дизайн ужасен. Ошибок трудно отследить, и через неделю у меня было > 10 патчей, которые мне нужны, чтобы сделать это основным. Позже я узнал, что некоторые сценарии написаны по-другому, но разработчики SIPr не очень отзывчивы, и для этого потребовалось много времени. Синхронизация действий многих агентов, если это сложная проблема, поскольку они предпочтут использовать основанную на событиях, но все еще однопоточную версию... это просто заставляет вас слишком сосредоточиться на "каком порядке это может случиться и обрабатывать ли я это правильно", вместо того, чтобы писать фактический тест.

• WinSIP

Коммерческое решение. Никогда не тестировал его должным образом, так как базовая функциональность отсутствует в оценочной версии, и трудно тратить столько денег на то, что вы не уверены, работает...

• SipUnit

Java-решение, повторно использующее стек Jain-SIP. Он может делать практически любой сценарий и достаточно хорош. Он пытается сделать все неблокирующее/действие основанное на тех же проблемах, что и SIPr, но в этом случае тривиально сделать его параллельным/потоковым. У этого есть своя доля ошибок, поэтому не все хорошо работает в пакете ванили, но большая часть материала патче. Разработчики, похоже, заняты другими проектами, поэтому они не обновляются в течение длительного времени. Если вам нужны переводы, наличие, диалог-информация, пользовательские сообщения, обработка RTP и т.д., Вам придется написать свои собственные модификации для их поддержки. Это плохо для тестирования производительности.

Если вы такой Java-hater, как я, его можно использовать простым способом из Jython, JRuby или любого другого JVM-языка.

В конце концов, я выбрал SIPunit как наименее разрушенное/злое/непригодное для использования решение. Это отнюдь не идеально, но... он работает в большинстве случаев. Если бы я снова выполнял проект со всеми этими знаниями, я бы, вероятно, повторно использовал конфигурации SIPp и попытался написать собственное, разумное решение, которое использует правильную потоковую обработку - но это, по крайней мере, ½-летний проект для одного человека, чтобы сделать его хорошим достаточно для производства.

Ответ 3

Попробуйте SIPInspector. Это утилита, основанная на JAVA, для повторного создания различных сценариев сигнализации SIP. Он может воспроизводить RTP и стресс-тест вашей системы. Поскольку он написан в JAVA, он очень портативен и работает на разных системах разведения. Легче для пользователя, чем SIPp.

Ответ 4

Что вы хотите проверить отдельно от того, прошел ли вызов? Не можете ли вы просто вызвать устройство B с устройства A и посмотреть, сможете ли вы поговорить через соединение? Если вы хотите взглянуть на отправляемые пакеты, вы должны изучить wireshark.