[sr-dev] Kamailio as IMS - pcscf and multiple registration entries

Jason Penton jason.penton at gmail.com
Fri Mar 21 16:49:29 CET 2014


Hey Daniel,

actually your problem is slightly different. Your multiple contact problem
is actually at the S-CSCF and not the P. It is the S-CSCF that does a
lookup on an impu and forks to all registered contacts (via the P-CSCF
because of path header). However, there is a modparam on S-CSCF to limit
the number of simultaneous contacts.

modparam("ims_registrar_scscf", max_contacts", 1);

Cheers
Jason



On Fri, Mar 21, 2014 at 4:33 PM, Daniel Ciprus <daniel.ciprus at acision.com>wrote:

>  Thank you Jason,
>
> So once tcp session is gone, reg entry will be removed from hash table
> then ? Is this correct statement ?
>
> On 03/21/2014 10:11 AM, Jason Penton wrote:
>
> Ill release new pcscf code in the next few days. New hash is on ip only.
> This is mainly because with ipsec you have secure and insecure ports.... So
> we have to have it like that
>
> The result however should help your situation too
>
> --
> Sent using my phone and may be brief, to the point or contain typos
> On Mar 21, 2014 4:05 PM, "Daniel Ciprus" <daniel.ciprus at acision.com>
> wrote:
>
>> All,
>>
>> This is just a placeholder for issue we're facing in our deployment of
>> Kamailio IMS core : client uses TCP to send REGISTER. Occasionally client
>> crashes/lost connection so new REGISTER is sent towards P-CSCF. Instead of
>> removing old registration (there is no way to match these obviously) P-CSCF
>> will create new entry and keeps this information for future use. Once SIP
>> request is sent out to the contact, P-CSCF uses all registration entries in
>> the memory and forks requests to all destinations (which are in most cases
>> unreachable). This creates flood of timeouts from S-CSCF towards AS and
>> sometimes bad timing is even  causing calls not being processed since 408
>> Request Timeout is delivered sooner than 200 OK. I'm pretty sure Carsten is
>> aware about this issue that's why this note at very beginning about
>> "placeholder"
>>
>> thank you
>> Dan.
>>
>> --
>> *Daniel Ciprus*
>> Integration engineer
>> http://www.acision.com
>>
>> 9954 Mayland Dr
>> Suite 3100
>> Richmond, VA 23233
>> USA
>> T: +1 804 762 5601
>> E: daniel.ciprus at acision.com
>>
>> ------------------------------
>> This e-mail and any attachment is for authorised use by the intended
>> recipient(s) only. It may contain proprietary material, confidential
>> information and/or be subject to legal privilege. It should not be copied,
>> disclosed to, retained or used by, any other party. If you are not an
>> intended recipient then please promptly delete this e-mail and any
>> attachment and all copies and inform the sender. Thank you for
>> understanding.
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
> --
> *Daniel Ciprus*
> Integration engineer
> http://www.acision.com
>
> 9954 Mayland Dr
> Suite 3100
> Richmond, VA 23233
> USA
> T: +1 804 762 5601
> E: daniel.ciprus at acision.com
>
> ------------------------------
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you for
> understanding.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140321/4062aa77/attachment-0001.html>


More information about the sr-dev mailing list