[reSIProcate] sip stack limitations

Daniel Pocock daniel at readytechnology.co.uk
Sun Jul 2 03:50:28 CDT 2006



Jyotshna Cherukuri wrote:

>    Hi,
>           
>  We implemented a Third party Call Control ( Bridge) using reciprocate  stack and we experience problems with the stack when we send  large amount of requests to the stack . I am  using a single threaded stack for my application and I see the messages coming  onto the NIC card but the stack is unable to receive them as it is busy  processing some other functions which results in lot of 408 requests from other  applications and gateways. 
>           
>  Any suggestions regarding this request would be appreciated  and I am wondering whether running sipstack in its own thread might eliminate this  problem to some extent? 
>  
>
a) Are you running on Linux or another platform?  We handle quite a 
large call volume on Linux, but I can't comment on how the stack 
performs on Windows.

b) Have you got debugging enabled?  Debugging will slow the application, 
writing to stderr, calls to a syslog destination that is synchronous, 
and similar code will slow your application and make response times 
unbearable.

c) Are you doing any database access, e.g. for authentication or CDR 
logging?  We start a separate thread for each database/RADIUS query, 
that way the SIP and DUM stacks can process other packets while waiting 
for authentication results.  The query threads then use the `post()' 
method to send their results back to the stack asynchronously.




More information about the resiprocate-devel mailing list