[sr-dev] Problem with Registration on pcscf

Fri Feb 7 14:17:35 CET 2014

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 at ims.test
IMPU: imsi at ims.test
Contact: imsi at ip:port.....

At this stage in usrloc the hash will be over the contact imsi at ip:port

Let's say this SIM has an implicit registration set which includes for
example:
tel:1234
sip:1234 at ims.test, and
sip:jason.penton at 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 at 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 at 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

On Thu, Feb 6, 2014 at 4:50 PM, Hugh Waite <hugh.waite at crocodile-rcs.com>wrote:

> Hi,
> 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.
>
> 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.
>
> We believe that the multiple entries should be returned and looped round
> to check for matches.
> 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.
>
> Regards,
> Hugh
>
>
> On 05/02/2014 14:09, Carsten Bock wrote:
>
>> Hi Paul,
>>
>> since probably i'm the guilty one, i would check. In order to quickly
>> reproduce that issue, some quick questions:
>> - you are using GIT master? I've made some changes in GIT master
>> (compared to 4.1) in terms of detecting, if a user is registered...
>>
>> Can you send me the SIPP-Scripts?
>> I will then check next week for this topic.
>>
>> Thanks for testing,
>> Carsten
>>
>>
>>
>> 2014-01-29 Paul Pankhurst <paul at crocodile-rcs.com>:
>>
>>> Hi Jason,
>>>
>>>
>>>
>>> I've not done anything further on this since Friday, as I've been busy on
>>> other things.
>>>
>>>
>>>
>>> If you have trouble reproducing it I can send you my sipp scripts and
>>> some
>>> wireshark traces if it helps.
>>>
>>>
>>>
>>> Paul
>>>
>>>
>>>
>>>
>>>
>>> From: sr-dev-bounces at lists.sip-router.org
>>> [mailto:sr-dev-bounces at lists.sip-router.org] On Behalf Of Jason Penton
>>> Sent: 29 January 2014 07:52
>>> To: Kamailio (SER) - Development Mailing List
>>> Subject: Re: [sr-dev] Problem with Registration on pcscf
>>>
>>>
>>>
>>> Hey Paul,
>>>
>>>
>>>
>>> Sorry for the delay on this. I had missed it. I will see if I can
>>> re-create
>>> and get back to you. Have you maanged to do any more testing since?
>>>
>>>
>>>
>>> Cheers
>>>
>>> Jason
>>>
>>>
>>>
>>> On Fri, Jan 24, 2014 at 5:42 PM, Paul Pankhurst <paul at crocodile-rcs.com>
>>> wrote:
>>>
>>> I've noticed a problem with registrations on the pcscf when doing some
>>> testing with sipp
>>>
>>> If I send in a REGISTER with SIPP followed by an INVITE calls go through
>>> my
>>> system no problem.
>>> If I then stop the sipp script and run it again, I find that although the
>>> registration succeeds, subsequent INVITES are rejected telling me that I
>>> have not registered!
>>> If I unregister at the end of my script everything is fine, and the
>>> problem
>>> goes away after the original REGISTRATION times out, so this led me to
>>> think
>>> that we had a problem with multiple registrations entries in the system.
>>>
>>> The problem seems to be a result of the fact that sipp always places the
>>> same ip address and port number on the contact line when using tcp
>>> connections.
>>>
>>> I've had a look through the code and believe that we are getting multiple
>>> entries in the usrloc hash table in this scenario, and ul_get_pcontact
>>> only
>>> ever returns the first one which causes pcscf_is_registered to
>>> incorrectly
>>> report that the UE is not registered.
>>>
>>> Paul
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>>
>>
>>
>
> --
> Hugh Waite
> Principal Design Engineer
> Crocodile RCS Ltd.
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140207/d8bf2a7c/attachment.html>