Hi guys,
just had a look at this and in my opinion there are a few problems here. Firstly and most NB, I think the hash is incorrect. The hash function should be over IP:PORT:(maybe proto too) and not include the user part, etc. IMO the P-CSCF cares about "devices" ie. IP;PORT;PROTO and their associated IMPUs. Let me give an example:
let's say you register a 4G phone using USIM. The device will register with something like:
IMPI: imsi@ims.test
IMPU: imsi@ims.test
Contact: imsi@ip:port.....
At this stage in usrloc the hash will be over the contact imsi@ip:port
Let's say this SIM has an implicit registration set which includes for example:
tel:1234
sip:1234@ims.test, and
sip:jason.penton@ims.test.
Now, when I make a call from my device my contact *could* be either of my unbarred IMPUs as the user part.... For example,
1234@10.0.0.10:4434. In fact, there is nothing stopping a UE from using it's contact as just 10.0.0.10:443... ie without userpart.
The above scenario will fail in the current codebase as the hash that stored my original contact was based on a different user part (viz, imsi@ip:port).
The structure in usrloc should be IMO:
device (IP:PRT:PROTO) => list of associated IMPUs
Then, coming to the search,, we can have two overloaded getPcontacts. One that will return a list of contacts built from the list if IMPUs associated with the device and second which can be overloaded to send in more information in the hope that you only return one contact. Here you can pass in things like received port, userpart, etc, etc. If you use the first version then you will have to search through the list for whichever contact you are looking for in your consumer code.
Please let me know what you guys think so I can proceed on this. Currently it is breaking as well in our tests with 4G devices....
Cheers
Jason