Отвечает ли сервер регистратора методу SIP OPTIONS?

Question

Я делаю SIP-телефон и должен разработать функцию поддержки нескольких регистраций.Если основной сервер регистратора для телефона не работает, телефон должен автоматически зарегистрироваться на вторичном регистраторе и снова вернуться к первичному, когда основной регистратор активен.У меня вопрос: как определить, что первичный регистратор снова стал активным.Могу ли я отправить метод OPTIONS со своего телефона на мой основной сервер регистратора, будет ли регистратор отправлять на него ответ, как это делает любой другой прокси-сервер?Если я не получаю от него ответа, могу ли я предположить, что первичный регистратор все еще не подключен, и мне следует продолжить работу со вторичным регистратором.

В SIP RFC 3261 я прочитал, что «ОПЦИИ SIP-метода позволяет UA запрашиватьдругой UA или прокси-сервер относительно его возможностей. "и
"Если не получен ответ для метода OPTIONS, уровень транзакции может вернуть ошибку тайм-аута. Это может указывать на то, что цель недоступна и, следовательно, недоступна."

Пожалуйста, скажите мне, это правильный путьреализовать?

Answer 1

Запрос OPTIONS широко используется в различных программах SIP как механизм поддержания активности NAT. Это печальная ситуация, поскольку запросы OPTIONS могут потребовать значительного объема обработки на SIP-сервере. Таким образом, вы часто найдете ответ прокси-сервера SIP с ответом «ОК», не обрабатывая их в соответствии с RFC 3261, чтобы избежать лишней ненужной обработки.

В вашем случае, вероятно, было бы достаточно беспокоиться только о сбое, если вы отправили запрос REGISTER, который не получил ответа в течение периода ожидания транзакции (32 с по умолчанию). Вы можете настроить свой SIP-телефон так, чтобы он всегда сначала пробовал первичного регистратора при приближении интервала истечения срока регистрации, что означало бы, что вы всегда находитесь на первичном сервере, если он доступен.

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

Answer 2

Вы должны вместо этого посмотреть, как другие справились с этим. Например, см. Тесты соответствия Broadsoft для конечных точек; у них есть несколько тестов, в частности, о том, как справиться с резервным сервером. (Также, как это взаимодействует с DNS SRV.)