IMS Call Failure When Dialing with “+” Prefix

[Shah-Nj]

Environment
Core: Open5GS IMS lab
SIP Proxy: Kamailio (suspected)
HSS/UDM: PyHSS
UE: iPhone (SIP/VoLTE test client)
Network ranges:
UE SIP: 10.45.0.2 / 10.45.0.3
server ip is 192.168.159.116

When initiating a call from iPhone contacts, the dialed number is automatically converted into E.164 format with a “+” prefix (e.g. +33700000001).

This causes call routing failure in the IMS lab.

INVITE 33700000002@ims.mnc001.mc → +33700000001 ❌ REJECTED
INVITE 33700000002@ims.mnc001.mc → 33700000001;phone-context=... ✔ COMPLETED

Actual Behavior
INVITE with +33700000001 is rejected / not routed correctly
INVITE with phone-context or without + succeeds
PyHSS does not appear to normalize or match +E.164 format
Subscriber is treated as “not available” when + is present

Expected Behavior
IMS core should correctly normalize or route:
+33700000001
33700000001
tel:+33700000001;phone-context=...

All should resolve to the same IMS public identity.

🔍 Suspected Root Cause

Likely one (or more) of the following:

1. Kamailio routing issue
   No normalization from +E.164 → IMS URI format
   Missing or misconfigured:
   userloc
   pvar transformations
   uac_replace_from
   dialplan rules

2. IMS identity mismatch

PyHSS subscriber stored as:

33700000001@ims.mnc001.mc

But INVITE arrives as:

sip:+33700000001@ims.mnc001.mc
No alias mapping for +E.164
3. Missing TEL URI handling

No support for:

tel:+33...
sip:+33...

🧪 Notes
Adding + manually in SIP INVITE does not resolve routing in PyHSS
iPhone automatically prepends + based on contact format (normal iOS behavior)
PCAP attached for full SIP trace analysis
📎 Attachments
SIP PCAP capture (included)
Call flow logs (optional)

test_pcap.zip

[herlesupreeth]

There is no handling of + in kamailio. The modification is not needed in pyhss but rather in kamailio ICSCF

[Shah-Nj]

The failing call returns 604 "Does not exist anywhere". The same subscriber is reachable when called as 33700000001;phone-context... but not as +33700000001. Is the expected fix to normalize $rU in route[initial_request] before I_perform_location_information_request() so that E.164 numbers with a leading '+' are converted to the format stored in the HSS?

[herlesupreeth]

Is the expected fix to normalize $rU in route[initial_request] before I_perform_location_information_request() so that E.164 numbers with a leading '+' are converted to the format stored in the HSS?

I think so. Since I havent used + while dialing I am not sure thats all is enough to get it working under all scenarios