7 Feb
2014
7 Feb
'14
6:17 p.m.
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(a)ims.test
IMPU: imsi(a)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
On Thu, Feb 6, 2014 at 4:50 PM, Hugh Waite <hugh.waite(a)crocodile-rcs.com>wrote;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(a)crocodile-rcs.com>om>:
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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(a)lists.sip-router.org
[mailto:sr-dev-bounces@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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev