iphonednssipltegemalto

P-CSCF Discovery not being initiated in LTE Procedure in an Emulated LTE Network

I am trying to simulate an LTE network using a Agilent's E6621A and an iPhone 6 Plus in order to experiment on a VoLTE connection. According to the logging softwares I am using, the UE successfully completes its RRC Functions (including the RRCConnectionReconfiguration step, which is supposedly where the P-CSCF Discovery is supposed to happen) with no errors and just stops there before issuing any registration or subscription message. As mentioned, no flag is being thrown to indicate a setup error. According to several sources, the below APN 1 should be subscribing to the SIP server app that is being run, however that never occurs according to network sniffing.

Our current setup is as follows:

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

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

SIM: ID=Gemalto LTE Advanced R8 Test UICC, ISIM= 001010123456789@ims.mnc01.mcc.001.3gppnetwork.org, Authentication=Milenage

UE: Type=Apple iPhone 6 Plus running iOS 8.1.2, Cellular Carrier: Internet=VZWINTERNET, MMS=apn.vzims.com via the E6621A

We are running this simulated environment on a IPv6 capable local area network with IPv6 capable computers. The SIP server acts as both a DNS lookup server and as a IMS-SIP server, however this SIP server cannot be ID'd by the domain that it has been given by the SIP application (test.3gpp.com; this is not 3gpp.org) unless the other side uses 192.168.1.230 as its DNS.

This obviously isn't an authentication issue since connections on both APNs seem to be fine (I can ping each APN fine, although they often tend to experience ping timeouts due to a configuration I have yet to optimize) and the fact that it gets past the initial AttachAccept message.

Is there any part of the setup that you see above that is incorrect? If not, is there steps I should take to see what is preventing the P-CSCF from being successful?

If you need the logger/sniffer traces, please let me know. Do note that if you do need them, the logger traces (which keep track of all E6621A events) require a special dll and version 1.10 of Wireshark (plus a bit of setup).

Solution

  • I found out that there were a few things wrong with my setup.

    1. In order for the iPhone 6S+ to support VoLTE, it had to be running at minimum iOS 9, not 8.
    2. Because of the Update all the way to iOS 10.3.1, the CarrierLabs Software and the SIM I am using require that the Data APN be "ims", both on the iPhone and on the PXT; (otherwise I get a PDNConnectivity Request issue that is constantly looking for "ims").
    3. I also recently figured out (by trying to use it with a Free Open-Source SIP server) that the white paper I have been following has the setup all wrong when it comes to the Gateway. Instead of setting the gateway to 192.168.1.1 (for both the PXT and the E-EPCE), both the PXT gateway and E-EPCE gateway must be set to the server, otherwise it automatically forwards to our router, which prevents the receiving computer from preforming any reaction to it. In other words, I had to set the PXT's gateway to 192.168.1.230 (or 192.168.1.12 for the Open-Source) in order for it to work. I believe the cause behind this is due to the fact that the PXT is running Windows XP.

    That being said, I am having authentication issues between the iPhone and Opensource Server as seen in the following two posts: