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
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@crocodile-rcs.comwrote:
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@crocodile-rcs.com:
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 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
On Thu, Feb 6, 2014 at 4:50 PM, Hugh Waite hugh.waite@crocodile-rcs.comwrote:
Hi Hugh, Hi Paul.
any chance, that you send us your SIPP-scripts? We can test all our own use-cases (but they work already), but in order to fix (and correctly understand) this, we need to reproduce your problem...
Thanks, Carsten
2014-02-06 Hugh Waite hugh.waite@crocodile-rcs.com:
Hi Carsten,
I'll tar up the scripts and send them across to your direct email shortly
Paul
-----Original Message----- From: sr-dev-bounces@lists.sip-router.org [mailto:sr-dev-bounces@lists.sip-router.org] On Behalf Of Carsten Bock Sent: 07 February 2014 16:02 To: Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] Problem with Registration on pcscf
Hi Hugh, Hi Paul.
any chance, that you send us your SIPP-scripts? We can test all our own use-cases (but they work already), but in order to fix (and correctly understand) this, we need to reproduce your problem...
Thanks, Carsten
2014-02-06 Hugh Waite hugh.waite@crocodile-rcs.com:
-- Carsten Bock CEO (Geschäftsführer)
ng-voice GmbH Schomburgstr. 80 D-22767 Hamburg / Germany
http://www.ng-voice.com mailto:carsten@ng-voice.com
Office +49 40 34927219 Fax +49 40 34927220
Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Carsten Bock -
Hugh Waite -
Jason Penton -
Paul Pankhurst