Если SIP UAC падает в середине вызова SIP, каково ожидаемое поведение UAS и удаленного UAC? Предположим, что один UAS соединяет оба UAC в вызове.Авария SAC UAC во время разговора
Рассматривается ли этот сценарий в документе RFC/draft. Если да, то кто-нибудь может мне это сказать?
Для основного стандарта SIP (RFC 3261) нет необходимости проверять, остался ли другой конец вызова, и он оставлен разработчикам. На практике пользовательский агент обычно обнаруживал, что не было пакетов RTP за период (например, 60 секунд) и повесить вызов.
Как и все аспекты SIP, существует расширение RFC, которое имеет отношение к таймерам сеанса SIP (RFC 4028), которое документирует способ обработки тайм-аутов сеанса на уровне SIP. Хотя, поскольку он не входит в базовую стандартную поддержку, он будет отличаться.
Другой вариант - посмотреть поток RTP. Если он исчезнет, это может стать признаком краха. Он также может исчезнуть после RE-INVITE, хотя
UAS несет ответственность за прекращение сеанса для другого UAC [Выход], если он обнаруживает, что UAC [Ingress] не отвечает или наоборот.
Таймеры сеанса определяют периодические проверки работоспособности, чтобы убедиться, что вызов активен на обоих концах вызова. Обычно во время согласования сигнализации UAC/UAS могут определить, кто будет выполнять проверки сеанса и через какие промежутки времени. Таким образом, на основе UAS, являющегося Refresher - Lack of Response, может инициировать его, чтобы завершить другой сеанс. И если его регенерирующий приемник, то отсутствие запроса после определенного интервала может заставить его закрыть сеанс. Но в этом случае обнаружение сбоя основывается на интервале времени обновления.
Другие механизмы обнаруживают поток RTP, если UAS все еще является частью среды между конечными точками. Существуют механизмы бездействия RTP, которые могут быть использованы для этого, которые могут определять, когда теряется конечная точка, а не просто удерживать или тишина на линии.
Использование протоколов, ориентированных на транспорт, может помочь устранить проблему, если вызовы имеют уникальное соединение, и его потеря может быть немедленно запущена в UAS для принятия корректирующих действий.
Каково поведение UAS в этом случае? Можете ли вы прокомментировать оба случая: (i) когда сеанс таймаута был согласован в соответствии с RFC 4028 и (ii), когда нет таймаута сеанса –