hello, I would like to check whether your application is overloaded about 250 cps. Maybe app accepted too much SIP requests but couldn't handle asap. INVITE will be retransmitted if Sipp couldn't recv 100 trying in 500ms. Use rtd to start a timer when sipp send INVITE and stop it when 100 trying is arriving. Then you can get 100 trying response average time at sipp UAC. If this time is more longer than network TTL at high load, I think you need tune performance at your app level. And don't forget use netstat to check your application UDP recv queue and system CPU resource. regards, Gang On Tue, Oct 19, 2010 at 11:12 PM, Michael Pfeuffer <pfeufferm at gmail.com>wrote: > Hi All, > > I'm working on a project using the simple pjsip interface. The basic > function is to act as a redirect server. Everything works well until I get > to about 250 CPS. At that point, I start getting timeouts for a few of the > INVITEs, and the endpoint pool starts growing, specifically, the udp and ua > pools: > > before: > 10/19/10 08:55:13.134 17075:17077 sip_endpoint.c pjsip_endpt_dump() > 10/19/10 08:55:13.134 17075:17077 sip_endpoint.c Dumping endpoint > 0x8a44b6c: > 10/19/10 08:55:13.134 17075:17077 cachpool Dumping caching pool: > 10/19/10 08:55:13.134 17075:17077 cachpool Capacity=0, > max_capacity=0, used_cnt=6 > 10/19/10 08:55:13.134 17075:17077 cachpool Dumping all active > pools: > 10/19/10 08:55:13.134 17075:17077 cachpool pept0x8a44b08: > 46564 of 48096 (96%) used > 10/19/10 08:55:13.134 17075:17077 cachpool udp0x8a50b50: > 760 of 1024 (74%) used > 10/19/10 08:55:13.134 17075:17077 cachpool rtd0x8a50f60: > 6976 of 12096 (57%) used > 10/19/10 08:55:13.134 17075:17077 cachpool tsxlayer: > 4332 of 5120 (84%) used > 10/19/10 08:55:13.134 17075:17077 cachpool ua0x8a552c0: > 2320 of 3072 (75%) used > 10/19/10 08:55:13.134 17075:17077 cachpool evsub: > 780 of 1024 (76%) used > 10/19/10 08:55:13.134 17075:17077 cachpool Total 61732 of > 70432 (87 %) used! > 10/19/10 08:55:13.134 17075:17077 sip_endpoint.c Endpoint pool > capacity=48096, used_size=46564 > > after 1641 failed calls: > 10/19/10 08:57:48.527 17075:17077 sip_endpoint.c pjsip_endpt_dump() > 10/19/10 08:57:48.527 17075:17077 sip_endpoint.c Dumping endpoint > 0x8a44b6c: > 10/19/10 08:57:48.527 17075:17077 cachpool Dumping caching pool: > 10/19/10 08:57:48.527 17075:17077 cachpool Capacity=0, > max_capacity=0, used_cnt=6 > 10/19/10 08:57:48.527 17075:17077 cachpool Dumping all active > pools: > 10/19/10 08:57:48.527 17075:17077 cachpool pept0x8a44b08: > 46564 of 48096 (96%) used > 10/19/10 08:57:48.528 17075:17077 cachpool udp0x8a50b50: > 12100 of 12800 (94%) used <-- grew > 10/19/10 08:57:48.528 17075:17077 cachpool rtd0x8a50f60: > 6976 of 12096 (57%) used > 10/19/10 08:57:48.528 17075:17077 cachpool tsxlayer: > 4332 of 5120 (84%) used > 10/19/10 08:57:48.528 17075:17077 cachpool ua0x8a552c0: > 27152 of 28672 (94%) used <-- grew > 10/19/10 08:57:48.528 17075:17077 cachpool evsub: > 780 of 1024 (76%) used > 10/19/10 08:57:48.528 17075:17077 cachpool Total 97904 of > 107808 (90 %) used! > 10/19/10 08:57:48.528 17075:17077 sip_endpoint.c Endpoint pool > capacity=48096, used_size=46564 > > A few more clues: > 1) When the timeouts occur, I see the INVITE is retransmitted 4 times, but > my application never receives notification. > 2) The Call-ID of a missing INVITE never shows up in my application or the > pjsip logs. > 3) Other calls complete successfully during the time some are timing out. > 4) Traffic is generated using SIPp. > 5) The memory leak will grow to the point that the system becomes sluggish > and all calls fail. > 6) I'm using pjlb version 1.8, but have also verified this behavior with > version 1.3. > 7) This is a linux system. > 8) I don't see anything that look like error messages or warnings in the > pjsip log. > > My assumption is that the 1st INVITE has been passed to my on_rx_request() > callback function, but something (race condition?) prevents it from being > passed to my application. The library then ignores the retransmitted > INVITEs because it thinks the first one is already being handled. > > Any suggestions for sorting this out would be greatly appreciated. > > Thanks, > --Mike > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20101021/807f380e/attachment-0001.html>
