От rfc3261:
18.2 Серверы
18.2.1 Получение запросов
Сервер ДОЛЖЕН быть готов к приему запросов на любой IP-адрес, порт и транспорткомбинация, которая может быть результатом поиска DNS по SIP или SIPS URI [4], который раздается для связи
с этим сервером.В этом контексте «раздача»
включает в себя размещение URI в поле заголовка контакта в запросе REGISTER
или ответе на перенаправление, или в поле заголовка Record-Route в
запросе или ответе.URI также можно «раздать», разместив его
на веб-странице или визитной карточке.Также РЕКОМЕНДУЕТСЯ, чтобы сервер прослушивал запросы на портах SIP по умолчанию (5060 для TCP и UDP,
5061 для TLS через TCP) на всех открытых интерфейсах.Типичным исключением
могут быть частные сети или когда несколько экземпляров сервера
работают на одном хосте.Для любого порта и интерфейса
, который сервер прослушивает для UDP, он ДОЛЖЕН прослушивать этот же порт
и интерфейс для TCP.Это связано с тем, что сообщение может быть отправлено с использованием TCP, а не UDP, если оно слишком большое.В результате обратное
неверно.Серверу не нужно прослушивать UDP для
определенного адреса и порта только потому, что он прослушивает тот же адрес и порт для TCP.Конечно, могут быть и другие причины, по которым серверу необходимо прослушивать UDP для определенного адреса и порта.
На практике служба в реальной жизни ДОЛЖНА прослушивать весь обязательный транспорт.В противном случае у пользователей возникают проблемы.
В любом случае, клиент на практике будет использовать либо UDP, либо TCP (или TLS).Но не оба.Это действительно не должно быть проблемой, если A и B используют разные виды транспорта, потому что служба (здесь свободный режим) должна взаимодействовать с UDP для A и с TCP для B. Использование разного транспорта для каждого пользователя не должно быть причиной сбоя маршрутизации.
Для завершения SIP-серверы обычно не могут отправлять сообщения SIP-клиентам без существующего соединения (из-за NAT, брандмауэра ...).Клиенты SIP обычно создают REGISTER (и, таким образом, создают повторно используемое TCP-соединение или повторно используемую привязку UDP), затем при необходимости сервер всегда будет повторно использовать это TCP-подключение или UDP-привязку (так называемый обратный путь) для пересылкиновый запрос (ПРИГЛАШЕНИЕ).
В реальном мире другого пути нет!