La découverte P-CSCF n'est pas initiée dans la procédure LTE dans un réseau LTE émulé

Question

J'essaye de simuler un réseau LTE en utilisant un E6621A d'Agilent et un iPhone 6 Plus afin d'expérimenter sur une connexion VoLTE. Selon les logiciels de journalisation que j'utilise, l'UE termine avec succès ses fonctions RRC (y compris l'étape RRCConnectionReconfiguration, supposée être la destination de la découverte P-CSCF) sans erreur et s'arrête juste là avant d'émettre un message d'inscription ou d'abonnement . Comme mentionné, aucun drapeau n'est levé pour indiquer une erreur de configuration. Selon plusieurs sources, l'APN 1 ci-dessous doit être abonné à l'application de serveur SIP en cours d'exécution, mais cela ne se produit jamais en fonction de l'analyse du réseau.

Notre configuration actuelle est la suivante:

1 APN: Name = apn.vzims.com, Adresse = 192.168.1.51, DNS = 192.168.1.230, P-CSCF = 192.168.1.230, CauseCodeType = IPv4

2 APN: Name = VZWINTERNET, Adresse = 192.168.1.52, DNS = 10.4.1.1, P-CSCF = 192.168.1.230, CauseCodeType = IPv4

SIM: ID = Gemalto LTE A VANCÉES R8 test UICC, ISIM = 00101@ims.mnc01.mcc.001.3gppnetwork.org, authentification = MILENAGE

UE: type = Apple iPhone 6 Plus exécutant iOS 8.1.2, opérateurs de téléphonie: Internet = VZWINTERNET, MMS = apn.vzims.com via le E6621A

Nous exécutons cet environnement simulé sur un réseau local compatible IPv6 avec des ordinateurs compatibles IPv6. Le serveur SIP sert à la fois de serveur de recherche DNS et de serveur IMS-SIP, mais ce serveur SIP ne peut pas être identifié par le domaine qui lui a été attribué par l'application SIP (test.3gpp.com; ce n'est pas 3gpp.org) sauf si l'autre camp utilise 192.168.1.230 comme DNS. Ceci n'est évidemment pas un problème d'authentification car les connexions sur les deux APN semblent correctes (je peux pinguer chaque APN, même si elles ont souvent tendance à rencontrer des délais d'attente ping en raison d'une configuration que je dois encore optimiser) et le fait qu'il dépasse le message initial AttachAccept.

Y a-t-il une partie de la configuration que vous voyez ci-dessus qui est incorrecte? Sinon, y a-t-il des mesures que je devrais prendre pour voir ce qui empêche la réussite de la P-CSCF?

Si vous avez besoin des traces de logger/sniffer, faites le moi savoir. Notez que si vous en avez besoin, les traces du logger (qui gardent la trace de tous les événements E6621A) requièrent une DLL spéciale et la version 1.10 de Wireshark (plus un peu d'installation).

Answer 1

J'ai découvert qu'il y avait quelques problèmes avec ma configuration.

1. Pour l'iPhone 6S + pour soutenir Volte, il fallait courir au minimum 9 iOS, pas 8.
2. En raison de la mise à jour tout le chemin vers iOS 10.3.1, le logiciel et le CarrierLabs SIM que j'utilise exige que les données APN soient "ims", à la fois sur l'iPhone et sur le PXT; (sinon je reçois un problème de demande de PDNConnectivity qui cherche constamment "ims").
3. J'ai également récemment découvert (en essayant de l'utiliser avec un serveur SIP Open Source gratuit) que le livre blanc que j'ai suivi a la configuration tout faux quand il s'agit de la passerelle. Au lieu de définir la passerelle à 192.168.1.1 (à la fois pour le PXT et l'E-EPCE), la passerelle PXT et la passerelle E-EPCE doivent être configurées sur le serveur, sinon elles sont automatiquement transmises à notre routeur, ce qui empêche l'ordinateur récepteur de réagir. En d'autres termes, j'ai dû définir la passerelle de PXT à 192.168.1.230 (ou 192.168.1.12 pour l'Open-Source) pour que cela fonctionne. Je crois que la cause derrière cela est due au fait que le PXT fonctionne sous Windows XP.

Cela dit, j'ai des problèmes d'authentification entre l'iPhone et Opensource Server comme vu dans les deux postes suivants:

• Should a SIM Card and Cell Phone Produce an Authorization Response after Recieving "401 Forbidden"?
• Using FreePBX 13 With a Mock Cellular Network - FreeBPX Community Forums