Когда только устанавливается ipsec тоннель и телефон отправляет первый пакет в сторону ePDG, на роутере образуется соединение (если его можно так назвать) с временем жизни 10 сек. Это время регулируется параметром на роутере UPD Timeout, по умолч которое равно 10сек. Далее с ePDG приходит ответ, этому соединению присваевается таймер UDP stream timeout = 3 мин. Эти таймеры идут только вниз, и достгнув 0 роутер закрывает это соединение и удаляет "дырку" в NATе. Если телефон отправит хоть один пакет в сторону ePDG за эти 3 минуты, таймер снова обновляется до 3 минут.
А теперь самое интересное. В реалищазии ipsec/wi-fi calling/VoWIFI тонеле не на все пакеты от телефона обязан отвечать ePDG. Например на пакеты NAT keepalive размером 28байт, которые отправляются в среднем раз в 30 сек, ePDG не отвечает. Но эти пакеты сбравывают таймер на роутерах, как уже было сказано выше. Данный пакет служит для поддержания как раз этого UDP stream timeout таймера, и открытой "дырки" во всех NATах по пути следования от телефона до ePDG. Эти "дырки" это как раз тот обратный путь от ePDG, чтоб он мог пробудить телефон при входящем вызове. И таких NAT может быть на наших серых ip адресах минимум 2, один на домашнем роутере, другой на оборудовании провайдера, который называется CG-NAT и служит для экономии IP адресов провайдера.
Кроме пакета NAT keepalive телефон и ePDG обменивается и другими пакетами, например пакетами ESP для поддержания самого тоннеля, так и для поддержания SIP регистрации, который идет в этом тоннеле, на эти пакеты ePDG уже отвечает. Но эти пакеты пересылаются гораздо реже, в режиме ожидания от 600секунд до 1000секунд. Это не строго регламентировано стандартами 3gpp, а оператор сам это настраивает. Выбирается компромисс между расходом батареи телефона, нагрузкой на ePDG, и устойчивостью wi-fi calling, чтоб тоннель был как можно стабильнее. Так как любой обмен по wi-fi это чуть ли не самая энергозатратная часть телефона. Телефон пробуждает свой wi-fi итерфейс и старается отправить/принять все что накопилось в операционной системе, и потом снова его выключает. Так вот, если потеряются несколько пакетов NAT keepalive от телефона в сторону ePDG, ePDG считает тоннель потерянным и разрывает его, и удаляет SIP регистрацию. Телефон об этом не знает, он думает что все в порядке и продолжает слать NAT keepalive лишь до следующего сеанса согласования тоннеля или подтверждения SIP регистрации, тем самым обновляет UDP stream timeout. Соответственно, входящие вызовы не приходят по wi-fi calling. Но если попытаться позвонить (сделать исходящий вызов), телефон создаст новый тоннель и создаст SIP регистрацию.
Вторая сторона этой проблемы стабильности ipsec/wi-fi calling/VoWIFI - это то, как конкретный телефон, как его IMS стек реагирует на потерю тоннеля, какие тригеры стабильности ipsec/wi-fi calling/VoWIFI отслеживает и принимает решение, например полноценно зарегистрировать свой модем в 4G/VoLTE. Производители сами выбирают, какие триггеры считать “критическими”, это не строго регламентируется стандартами. Среди них наличие Wi-Fi link, смена IP (на телефоне в локальной сети или внешнего у провайдера), наличие sip регистрации, потеря ESP, и другие.
Поэтому этот параметр UDP stream timeout нужно наоборот уменьшать, чтоб роутер как можно быстрее удалил потерянное соединение и как можно быстрее телефон об этом узнал. Но там тонкая грань, требующая индивидуальных экспериментов, ибо можно поломать udp целом, и что то другое перестанет работать или будет работать с глюками.
В целом для wi-fi calling/VoWIFI нужен качественный интернет, стабильный, чтоб было меньше NAT по дороге. Желательно ipv6, где NAT нет вовсе. Где бы был высокий приоритет для протокола ipsec/wi-fi calling/VoWIFI уже на уровне wi-fi линка. В наших реалиях, когда в доме десятки роутеров потери пакетов начинаются на уровне wi-fi. Непонятно также как агрессивно настроен CG-NAT у проводного провайдера, что он делает с такими "малоактивными" udp соединениями, и каком приоритете udp в целом у провайдера. Так как одно дело потеря одного пакета в протоколе QUIC при серфинге в браузере, и другое дело потеря одного NAT keepalive в ipsec. Провайдеры стремяться экономить на ip адресах, и "размазывать" один адрес на много абонентов. Но как известно на одном ip адресе 65тыщ портов, за вычетом "нижних", которые нельзя использовать. А каждое сессия ipsec/wi-fi calling/VoWIFI это один порт.
зы Литературы по этому практически мало. Это то что удалось выяснить пообщавшись с ИИ, и понаблюдав за трафиком между телефоном и ePDG. Так что это без претензии на какую то истинность, сугубо точка зрения.
Робота послуги забезпечується з обмеженого переліку пристроїв абонентського обладнання (смартфони), які мають відповідне програмне забезпечення від виробника обладнання. На інших пристроях коректна робота послуги не гарантується.
Обмеження в роботі VoWiFi
У разі заміни USIM/eSIM необхідно через підтримку перепідключити послугу VoLTE та VoWiFi.
