Обнаружение P-CSCF не инициируется в процедуре LTE в эмулированной сети LTE

Question

Я пытаюсь смоделировать сеть LTE, используя Agilent E6621A и iPhone 6 Plus, чтобы поэкспериментировать с подключением VoLTE. В соответствии с программным обеспечением для ведения журналов, которое я использую, UE успешно завершает свои функции RRC (включая этап RRCConnectionReconfiguration, который предположительно происходит там, где должно происходить обнаружение P-CSCF) без ошибок и просто останавливается там перед выдачей любого сообщения регистрации или подписки, Как уже упоминалось, флаг не выставляется, чтобы указать на ошибку установки. Согласно нескольким источникам, нижеприведенный APN 1 должен подписываться на приложение SIP-сервера, которое выполняется, однако это никогда не происходит в соответствии с анализом сети.

Наша текущая настройка выглядит следующим образом:

APN 1: имя =apn.vzims.com, адрес = 192.168.1.51, DNS = 192.168.1.230, P-CSCF = 192.168.1.230, CauseCodeType = IPv4

APN 2: имя =VZWINTERNET, адрес = 192.168.1.52, DNS = 10.4.1.1, P-CSCF = 192.168.1.230, CauseCodeType = IPv4

SIM-карта: ID=Gemalto LTE Advanced U8 Test UICC, ISIM= [e-mail], аутентификация = Milenage

UE: Тип =Apple iPhone 6 Plus под управлением iOS 8.1.2, оператор сотовой связи: Интернет =VZWINTERNET, MMS=apn.vzims.com через E6621A

Мы работаем в этой моделируемой среде в локальной сети с поддержкой IPv6 и компьютерами с поддержкой IPv6. Сервер SIP действует как сервер поиска DNS и как сервер IMS-SIP, однако этот сервер SIP не может быть идентифицирован доменом, который был задан приложением SIP (test.3gpp.com; это не 3gpp.org), если другая сторона не использует 192.168.1.230 в качестве своего DNS.

Это, очевидно, не проблема аутентификации, так как соединения на обеих APN кажутся нормальными (я могу нормально пропинговать каждую APN, хотя они часто имеют тенденцию испытывать таймауты пинга из-за конфигурации, которую я еще не оптимизировал) и факта, что это проходит мимо исходное сообщение AttachAccept.

Есть ли какая-то часть установки, которую вы видите выше, которая является неправильной? Если нет, то какие шаги я должен предпринять, чтобы увидеть, что мешает P-CSCF быть успешным?

Если вам нужны следы регистратора / сниффера, пожалуйста, дайте мне знать. Обратите внимание, что если они вам нужны, для трассировки регистратора (которая отслеживает все события E6621A) требуется специальный dll и версия 1.10 Wireshark (плюс немного настроек).

Answer 1

Я обнаружил, что с моей настройкой было несколько проблем.

1. Чтобы iPhone 6S+ поддерживал VoLTE, он должен был работать с минимальной iOS 9, а не 8.
2. В связи с полным обновлением до iOS 10.3.1, программное обеспечение CarrierLabs и используемая мной SIM-карта требуют, чтобы APN данных был "ims" как на iPhone, так и на PXT; (иначе я получаю проблему запроса PDNConnectivity, которая постоянно ищет "ims").
3. Я также недавно выяснил (пытаясь использовать его со свободным SIP-сервером с открытым исходным кодом), что в документе, которому я следую, настройки неверны, когда речь идет о шлюзе. Вместо установки шлюза на 192.168.1.1 (как для PXT, так и для E-EPCE), оба шлюза PXT и шлюз E-EPCE должны быть установлены на сервере, в противном случае он автоматически перенаправляется на наш маршрутизатор, что предотвращает получение компьютера-получателя. от предварительного реагирования на это. Другими словами, я должен был установить шлюз PXT на 192.168.1.230 (или 192.168.1.12 для Open-Source), чтобы он работал. Я считаю, что причина этого заключается в том, что PXT работает под управлением Windows XP.

При этом у меня возникают проблемы с аутентификацией между iPhone и Opensource Server, как видно из следующих двух постов:

• Должна ли SIM-карта и мобильный телефон выдавать авторизационный ответ после получения "401 Forbidden"?
• Использование FreePBX 13 с фиктивной сотовой сетью - Форумы сообщества FreeBPX