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@acision.commailto:daniel.ciprus@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.
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@acision.commailto:daniel.ciprus@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 5601tel:%2B1%20804%20762%205601 E: daniel.ciprus@acision.commailto:daniel.ciprus@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@lists.sip-router.orgmailto:sr-dev@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@acision.commailto:daniel.ciprus@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.
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@acision.comwrote:
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@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@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@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@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.
You answered question which I received few minutes ago from my bosses ! How did you know ? ;)
thanks !
On 03/21/2014 11:49 AM, Jason Penton wrote: 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@acision.commailto:daniel.ciprus@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@acision.commailto:daniel.ciprus@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 5601tel:%2B1%20804%20762%205601 E: daniel.ciprus@acision.commailto:daniel.ciprus@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@lists.sip-router.orgmailto:sr-dev@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 5601tel:%2B1%20804%20762%205601 E: daniel.ciprus@acision.commailto:daniel.ciprus@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.
-- 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@acision.commailto:daniel.ciprus@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.
;-)
-- Sent using my phone and may be brief, to the point or contain typos -- On Mar 21, 2014 7:11 PM, "Daniel Ciprus" daniel.ciprus@acision.com wrote:
You answered question which I received few minutes ago from my bosses ! How did you know ? ;)
thanks !
On 03/21/2014 11:49 AM, Jason Penton wrote:
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@acision.comwrote:
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@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@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@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@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.
-- *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@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.
-
Daniel Ciprus -
Jason Penton