vonr sip 401 error

[shuimoshusheng]

When I was testing VONR, I encountered a SIP registration 401 error. The error message and packet capture configuration information are as follows. Thank you！

here is pcap：
vonr.zip

pcscf log ：

pyhss config:
`

APN

{
"apn_id": 1,
"qci": 9,
"nidd_scef_realm": null,
"apn": "internet",
"arp_priority": 4,
"nidd_mechanism": null,
"ip_version": 0,
"arp_preemption_capability": false,
"nidd_rds": null,
"pgw_address": null,
"arp_preemption_vulnerability": true,
"nidd_preferred_data_mode": null,
"sgw_address": null,
"charging_rule_list": null,
"last_modified": "2025-01-08T03:15:46Z",
"charging_characteristics": "0800",
"nbiot": false,
"apn_ambr_dl": 0,
"nidd_scef_id": null,
"apn_ambr_ul": 0
};
{
"apn_id": 2,
"qci": 9,
"nidd_scef_realm": null,
"apn": "ims",
"arp_priority": 4,
"nidd_mechanism": null,
"ip_version": 0,
"arp_preemption_capability": false,
"nidd_rds": null,
"pgw_address": null,
"arp_preemption_vulnerability": true,
"nidd_preferred_data_mode": null,
"sgw_address": null,
"charging_rule_list": null,
"last_modified": "2025-01-08T03:16:55Z",
"charging_characteristics": "0800",
"nbiot": false,
"apn_ambr_dl": 0,
"nidd_scef_id": null,
"apn_ambr_ul": 0
};

AUC1

{
"ki": "00112233445566778899AABBCCDDEEFF",
"opc": "000102030405060708090A0B0C0D0E0F",
"amf": "8000",
"sqn": 0,
"imsi": "466920000000001"
},
{
"amf": "8000",
"lpa": null,
"adm1": null,
"sqn": 0,
"pin1": null,
"misc1": null,
"iccid": null,
"pin2": null,
"misc2": null,
"imsi": "466920000000001",
"puk1": null,
"misc3": null,
"batch_name": null,
"puk2": null,
"misc4": null,
"auc_id": 1,
"sim_vendor": null,
"kid": null,
"last_modified": "2025-01-08T03:19:55Z",
"ki": "00112233445566778899AABBCCDDEEFF",
"esim": false,
"psk": null,
"opc": "000102030405060708090A0B0C0D0E0F",
"des": null
};

AUC2

{
"ki": "00112233445566778899AABBCCDDEEFF",
"opc": "000102030405060708090A0B0C0D0E0F",
"amf": "8000",
"sqn": 0,
"imsi": "466920000000002"
},
{
"amf": "8000",
"lpa": null,
"adm1": null,
"sqn": 0,
"pin1": null,
"misc1": null,
"iccid": null,
"pin2": null,
"misc2": null,
"imsi": "466920000000002",
"puk1": null,
"misc3": null,
"batch_name": null,
"puk2": null,
"misc4": null,
"auc_id": 2,
"sim_vendor": null,
"kid": null,
"last_modified": "2025-01-08T03:20:18Z",
"ki": "00112233445566778899AABBCCDDEEFF",
"esim": false,
"psk": null,
"opc": "000102030405060708090A0B0C0D0E0F",
"des": null
};

subscriber 1

{
"imsi": "466920000000001",
"enabled": true,
"auc_id": 1,
"default_apn": 1,
"apn_list": "1,2",
"msisdn": "8613912345678",
"ue_ambr_dl": 0,
"ue_ambr_ul": 0
},
{
"imsi": "466920000000001",
"nam": 0,
"serving_mme_peer": null,
"enabled": true,
"roaming_enabled": true,
"last_modified": "2025-01-08T03:23:11Z",
"auc_id": 1,
"roaming_rule_list": null,
"default_apn": 1,
"subscribed_rau_tau_timer": 300,
"apn_list": "1,2",
"serving_mme": null,
"msisdn": "8613912345678",
"serving_mme_timestamp": null,
"subscriber_id": 1,
"ue_ambr_dl": 0,
"serving_mme_realm": null,
"ue_ambr_ul": 0
};

subscriber 2

{
"imsi": "466920000000002",
"enabled": true,
"auc_id": 2,
"default_apn": 1,
"apn_list": "1,2",
"msisdn": "8613912345679",
"ue_ambr_dl": 0,
"ue_ambr_ul": 0
},
{
"imsi": "466920000000002",
"nam": 0,
"serving_mme_peer": null,
"enabled": true,
"roaming_enabled": true,
"last_modified": "2025-01-08T03:24:12Z",
"auc_id": 2,
"roaming_rule_list": null,
"default_apn": 1,
"subscribed_rau_tau_timer": 300,
"apn_list": "1,2",
"serving_mme": null,
"msisdn": "8613912345679",
"serving_mme_timestamp": null,
"subscriber_id": 2,
"ue_ambr_dl": 0,
"serving_mme_realm": null,
"ue_ambr_ul": 0
};

IMS SUBSCRIBER 1

{
"imsi": "466920000000001",
"msisdn": "8613912345678",
"sh_profile": "string",
"scscf_peer": "scscf.ims.mnc092.mcc466.3gppnetwork.org",
"msisdn_list": "[8613912345678]",
"ifc_path": "default_ifc.xml",
"scscf": "sip:scscf.ims.mnc092.mcc466.3gppnetwork.org:6060",
"scscf_realm": "ims.mnc092.mcc466.3gppnetwork.org"
},
{
"ifc_path": "default_ifc.xml",
"sh_profile": "string",
"pcscf": null,
"scscf": "sip:scscf.ims.mnc092.mcc466.3gppnetwork.org:6060",
"pcscf_realm": null,
"scscf_timestamp": null,
"pcscf_active_session": null,
"scscf_realm": "ims.mnc092.mcc466.3gppnetwork.org",
"ims_subscriber_id": 1,
"pcscf_timestamp": null,
"scscf_peer": "scscf.ims.mnc092.mcc466.3gppnetwork.org",
"msisdn": "8613912345678",
"pcscf_peer": null,
"sh_template_path": null,
"msisdn_list": "[8613912345678]",
"xcap_profile": null,
"last_modified": "2025-01-08T03:26:53Z",
"imsi": "466920000000001"
};

IMS SUBSCRIBER 2

{
"imsi": "466920000000002",
"msisdn": "8613912345679",
"sh_profile": "string",
"scscf_peer": "scscf.ims.mnc092.mcc466.3gppnetwork.org",
"msisdn_list": "[8613912345679]",
"ifc_path": "default_ifc.xml",
"scscf": "sip:scscf.ims.mnc092.mcc466.3gppnetwork.org:6060",
"scscf_realm": "ims.mnc092.mcc466.3gppnetwork.org"
},
{
"ifc_path": "default_ifc.xml",
"sh_profile": "string",
"pcscf": null,
"scscf": "sip:scscf.ims.mnc092.mcc466.3gppnetwork.org:6060",
"pcscf_realm": null,
"scscf_timestamp": null,
"pcscf_active_session": null,
"scscf_realm": "ims.mnc092.mcc466.3gppnetwork.org",
"ims_subscriber_id": 2,
"pcscf_timestamp": null,
"scscf_peer": "scscf.ims.mnc092.mcc466.3gppnetwork.org",
"msisdn": "8613912345679",
"pcscf_peer": null,
"sh_template_path": null,
"msisdn_list": "[8613912345679]",
"xcap_profile": null,
"last_modified": "2025-01-08T03:27:11Z",
"imsi": "466920000000002"
}
`

[herlesupreeth]

401 is a authentication challenge sent by P-CSCF to UE and not an error. In your pcap I see UE is not responding to 401 challenge so I am suspecting your authentication parameters are incorrect (Ki, OP or OPc).

[shuimoshusheng]

401 is a authentication challenge sent by P-CSCF to UE and not an error. In your pcap I see UE is not responding to 401 challenge so I am suspecting your authentication parameters are incorrect (Ki, OP or OPc).

@herlesupreeth Thank you for your reply. I have checked the configuration and it is as follows:

1. SIM1 Config：
   

2. SIM2 Config:
   

3. Open5GS Config:
   
   

When I make a phone call, it prompts that the mobile network is unavailable.

[herlesupreeth]

its quite strange then because UE is getting authenticated with the same credentials in open5gs HSS but not in pyHSS

If you dont mind, rather than screenshot of open5gs webUI can you post here the subscriber details from mongodb?

[NUCLEAR-WAR]

the device at Frame# 605 is sending TCP SYNC on Port 6100 to build the IPSec Tunnel after the 401, but there is nor response on the SYNC from the P-CSCF not sure what is the reason, it repeat the try again and again, I noticed that the GTP Header is still there, therfore not sure if it reached the P-CSCF, as it should be removed by then.

[herlesupreeth]

If P-CSCF is not responding to TCP SYN packet on IPSec port then it means that SIM credentials (Ki, OP/OPc) is incorrect somewhere (either on the SIM or pyHSS). This is so because the ik and ck keys are used while setting up IPSec tunnels. And, these keys are derived based on (Ki, OP/OPc) and other keys

[NUCLEAR-WAR]

looking at the dump from PyHSS and Screenshots from Open5GS HSS/Sim reader Software, both seems fine, looking at the trace the register from the UE did not reach the P-CSCF to announce port-s/port-c to P-CSCF, it was sent from the UPF IP Address instead after the GTP Header has been removed Frame# 568, which make the P-CSCF expects IPSec with 172.22.0.8, I never saw in my tests that the UPF it self sends SIP Messages, it routes the traffic but does not act as SIP-UA, the P-CSCF is complaining in the logs about TCP connection to 172.22.0.8 which is the UPF and not the UE, the UPF for whatever reason rewrites the IP Header and change the UE IP with his IP, he should only remove the GTP Header and route the traffic towards the P-CSCF.
This is to me very strange and I saw it for the first time, maybe there is other reason, but the UPF sending SIP Register sounds to be the problem.

[shuimoshusheng]

@herlesupreeth @NUCLEAR-WAR
Thank you for your reply. Here is my open5gs subscription information:

[
  {
    _id: ObjectId('677ded428da2ed00308b5a16'),
    ambr: { downlink: { value: 1, unit: 3 }, uplink: { value: 1, unit: 3 } },
    schema_version: 1,
    msisdn: [],
    imeisv: '8639460618559978',
    mme_host: [],
    mme_realm: [],
    purge_flag: [],
    access_restriction_data: 32,
    subscriber_status: 0,
    operator_determined_barring: 0,
    network_access_mode: 0,
    subscribed_rau_tau_timer: 12,
    imsi: '466920000000001',
    security: {
      k: '00112233445566778899AABBCCDDEEFF',
      amf: '8000',
      op: null,
      opc: '000102030405060708090A0B0C0D0E0F',
      sqn: Long('35184374006033')
    },
    slice: [
      {
        _id: ObjectId('677ded428da2ed00308b5a17'),
        sst: 1,
        default_indicator: true,
        session: [
          {
            qos: {
              arp: {
                priority_level: 8,
                pre_emption_capability: 1,
                pre_emption_vulnerability: 1
              },
              index: 9
            },
            ambr: {
              downlink: { value: 1, unit: 3 },
              uplink: { value: 1, unit: 3 }
            },
            _id: ObjectId('677ded428da2ed00308b5a18'),
            name: 'internet',
            type: 1,
            pcc_rule: []
          },
          {
            qos: {
              arp: {
                priority_level: 1,
                pre_emption_capability: 1,
                pre_emption_vulnerability: 1
              },
              index: 5
            },
            ambr: {
              downlink: { value: 1, unit: 3 },
              uplink: { value: 1, unit: 3 }
            },
            _id: ObjectId('677ded428da2ed00308b5a19'),
            name: 'ims',
            type: 1,
            pcc_rule: []
          }
        ],
        sd: '000001'
      }
    ],
    __v: 0
  },
  {
    _id: ObjectId('677deda58da2ed00308b5a2d'),
    ambr: { downlink: { value: 1, unit: 3 }, uplink: { value: 1, unit: 3 } },
    schema_version: 1,
    msisdn: [],
    imeisv: '8609250495084620',
    mme_host: [],
    mme_realm: [],
    purge_flag: [],
    access_restriction_data: 32,
    subscriber_status: 0,
    operator_determined_barring: 0,
    network_access_mode: 0,
    subscribed_rau_tau_timer: 12,
    imsi: '466920000000002',
    security: {
      k: '00112233445566778899AABBCCDDEEFF',
      amf: '8000',
      op: null,
      opc: '000102030405060708090A0B0C0D0E0F',
      sqn: Long('1622683')
    },
    slice: [
      {
        _id: ObjectId('677deda58da2ed00308b5a2e'),
        sst: 1,
        default_indicator: true,
        session: [
          {
            qos: {
              arp: {
                priority_level: 8,
                pre_emption_capability: 1,
                pre_emption_vulnerability: 1
              },
              index: 9
            },
            ambr: {
              downlink: { value: 1, unit: 3 },
              uplink: { value: 1, unit: 3 }
            },
            _id: ObjectId('677deda58da2ed00308b5a2f'),
            name: 'internet',
            type: 1,
            pcc_rule: []
          },
          {
            qos: {
              arp: {
                priority_level: 1,
                pre_emption_capability: 1,
                pre_emption_vulnerability: 1
              },
              index: 5
            },
            ambr: {
              downlink: { value: 1, unit: 3 },
              uplink: { value: 1, unit: 3 }
            },
            _id: ObjectId('677deda58da2ed00308b5a30'),
            name: 'ims',
            type: 1,
            pcc_rule: []
          }
        ],
        sd: '000001'
      }
    ],
    __v: 0
  }
]

[shuimoshusheng]

I have a question, why does the P-CSCF log show a failure to connect to UPF tcp port 5060? SIP services should not appear on UPF, right？Thanks!

[herlesupreeth]

@shuimoshusheng are you sure OPc is correctly derived from Ki and OP?

I have a question, why does the P-CSCF log show a failure to connect to UPF tcp port 5060? SIP services should not appear on UPF, right？

UPF is nothing but PGW-U, so all the traffic (internet/ims etc.) has to pass through UPF and exit on SGi interface towards internet or IMS subsystem

[shuimoshusheng]

@herlesupreeth Thank you for your answer. Because I don't know the value of OP, OPC is not derived based on Key and OP. 😂，I will try to correctly derive the value.Using this CryptoTool should be the correct key and OPC, right？

[herlesupreeth]

I will try to correctly derive the value.Using this CryptoTool should be the correct key and OPC, right？

Yes, you could use that tool. Key and OP can be user defined, but OPc is derive from Key and OP.

[shuimoshusheng]

I will try to correctly derive the value.Using this CryptoTool should be the correct key and OPC, right？

Yes, you could use that tool. Key and OP can be user defined, but OPc is derive from Key and OP.

I have generated the correct OPC using this tool, but I am currently unable to make phone calls. This is the captured PCAP file:
vonr-n5-404.zip

pcscf logs：

pcf logs：

icscf logs:

smsc logs:

[Hampas-J]

@shuimoshusheng how did you resolve register issue with CryptoTool? it's caused by wrong key and opc?

[shuimoshusheng]

@Hampas-J

use this tool CryptoTool area to generate the correct ki opc.