Тестовая платформа SIP [закрывается]

Я ищу инструмент, который тестирует вызовы SIP. Платформа, которая звонит от устройства SIP к устройству SIP B и сообщает о результатах...

Какая-либо идея? Платформа моделирования была бы идеальна.

спасибо, cateof

18
задан ire_and_curses 4 March 2010 в 15:29
поделиться

3 ответа

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

9
ответ дан 30 November 2019 в 07:28
поделиться

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

-2
ответ дан 30 November 2019 в 07:28
поделиться

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

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

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

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

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

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

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

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

27
ответ дан 30 November 2019 в 07:28
поделиться
Другие вопросы по тегам:

Похожие вопросы: