<div dir="ltr">Hi guys,<div><br></div><div>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:</div>
<div><br></div><div>let's say you register a 4G phone using USIM. The device will register with something like:</div><div>IMPI: imsi@ims.test</div><div>IMPU: imsi@ims.test</div><div>Contact: imsi@ip:port.....</div><div>
<br></div><div>At this stage in usrloc the hash will be over the contact imsi@ip:port</div><div><br></div><div>Let's say this SIM has an implicit registration set which includes for example:</div><div>tel:1234</div><div>
sip:1234@ims.test, and</div><div>sip:jason.penton@ims.test.</div><div><br></div><div>Now, when I make a call from my device my contact *could* be either of my unbarred IMPUs as the user part.... For example, <a href="http://1234@10.0.0.10:4434">1234@10.0.0.10:4434</a>. In fact, there is nothing stopping a UE from using it's contact as just 10.0.0.10:443... ie without userpart.</div>
<div><br></div><div>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).</div><div><br></div><div>The structure in usrloc should be IMO:</div>
<div>device (IP:PRT:PROTO) => list of associated IMPUs</div><div><br></div><div>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.</div>
<div><br></div><div>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....</div><div><br></div><div>Cheers</div><div>Jason</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 4:50 PM, Hugh Waite <span dir="ltr"><<a href="mailto:hugh.waite@crocodile-rcs.com" target="_blank">hugh.waite@crocodile-rcs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
This system is using GIT master built on December 18th and has the 'fallback to ip' modparam set - which is being used in this case because all clients are behind a cloud based NAT.<br>
<br>
The problem occurs when there are multiple entries for a user in the usrloc table, but ul.get_pcontact(...) only ever returns one. which may not match the contact or the source IP/port.<br>
<br>
We believe that the multiple entries should be returned and looped round to check for matches.<br>
Multiple entries can be easily created by disconnecting a TCP client (or sipp script) without deregistering and connecting + registering again from a different ephemeral port.<br>
<br>
Regards,<br>
Hugh<div class="HOEnZb"><div class="h5"><br>
<br>
On 05/02/2014 14:09, Carsten Bock wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Paul,<br>
<br>
since probably i'm the guilty one, i would check. In order to quickly<br>
reproduce that issue, some quick questions:<br>
- you are using GIT master? I've made some changes in GIT master<br>
(compared to 4.1) in terms of detecting, if a user is registered...<br>
<br>
Can you send me the SIPP-Scripts?<br>
I will then check next week for this topic.<br>
<br>
Thanks for testing,<br>
Carsten<br>
<br>
<br>
<br>
2014-01-29 Paul Pankhurst <<a href="mailto:paul@crocodile-rcs.com" target="_blank">paul@crocodile-rcs.com</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Jason,<br>
<br>
<br>
<br>
I've not done anything further on this since Friday, as I've been busy on<br>
other things.<br>
<br>
<br>
<br>
If you have trouble reproducing it I can send you my sipp scripts and some<br>
wireshark traces if it helps.<br>
<br>
<br>
<br>
Paul<br>
<br>
<br>
<br>
<br>
<br>
From: <a href="mailto:sr-dev-bounces@lists.sip-router.org" target="_blank">sr-dev-bounces@lists.sip-<u></u>router.org</a><br>
[mailto:<a href="mailto:sr-dev-bounces@lists.sip-router.org" target="_blank">sr-dev-bounces@lists.<u></u>sip-router.org</a>] On Behalf Of Jason Penton<br>
Sent: 29 January 2014 07:52<br>
To: Kamailio (SER) - Development Mailing List<br>
Subject: Re: [sr-dev] Problem with Registration on pcscf<br>
<br>
<br>
<br>
Hey Paul,<br>
<br>
<br>
<br>
Sorry for the delay on this. I had missed it. I will see if I can re-create<br>
and get back to you. Have you maanged to do any more testing since?<br>
<br>
<br>
<br>
Cheers<br>
<br>
Jason<br>
<br>
<br>
<br>
On Fri, Jan 24, 2014 at 5:42 PM, Paul Pankhurst <<a href="mailto:paul@crocodile-rcs.com" target="_blank">paul@crocodile-rcs.com</a>><br>
wrote:<br>
<br>
I've noticed a problem with registrations on the pcscf when doing some<br>
testing with sipp<br>
<br>
If I send in a REGISTER with SIPP followed by an INVITE calls go through my<br>
system no problem.<br>
If I then stop the sipp script and run it again, I find that although the<br>
registration succeeds, subsequent INVITES are rejected telling me that I<br>
have not registered!<br>
If I unregister at the end of my script everything is fine, and the problem<br>
goes away after the original REGISTRATION times out, so this led me to think<br>
that we had a problem with multiple registrations entries in the system.<br>
<br>
The problem seems to be a result of the fact that sipp always places the<br>
same ip address and port number on the contact line when using tcp<br>
connections.<br>
<br>
I've had a look through the code and believe that we are getting multiple<br>
entries in the usrloc hash table in this scenario, and ul_get_pcontact only<br>
ever returns the first one which causes pcscf_is_registered to incorrectly<br>
report that the UE is not registered.<br>
<br>
Paul<br>
<br>
______________________________<u></u>_________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/<u></u>cgi-bin/mailman/listinfo/sr-<u></u>dev</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/<u></u>cgi-bin/mailman/listinfo/sr-<u></u>dev</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
-- <br></div></div><span class="HOEnZb"><font color="#888888">
Hugh Waite<br>
Principal Design Engineer<br>
Crocodile RCS Ltd.</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/<u></u>cgi-bin/mailman/listinfo/sr-<u></u>dev</a><br>
</div></div></blockquote></div><br></div>