Re: Incoming SIP message handling

I think you are building a Sip Servlet Container. As my experience,
well, after thread from Stack hands off the message instance to the
thread from ur pool, it is free again and can be used by stack for other
incoming messages, the request states are only some instances which
saved in stack. 
I have checked out the HTTP server as Tomcat, it does the same, do not
know how the java.net and system TCP/IP stack and thread pool work.

Interesting question, correct me if I am wrong. urs Lebing


On Fri, 2006-03-10 at 08:31 -0500, Becky McElroy wrote:
> Hi,
> 
> We have a situation with handling of incoming SIP requests to our 
> server. We use a thread pool in our server to take the incoming SIP 
> messages from the nist sip stack and hand them off to applications, and 
> the applications work on the messages off of the threads in the thread 
> pool. The reason we did this was to prevent an application processing a 
> message from taking a long time, thus blocking any more SIP messages 
> being received/processed until that application returned from processing 
> the message. So when a SIP message comes in, a thread in the pool is 
> selected to 'receive' the message from the stack and it returns back to 
> nist stack immediately. The application can then take as long as it 
> needs and other SIP messages can continue to be received and processed 
> by other applications. The problem comes in because when the thread pool 
> thread returns from receiving the message, the stack thinks the message 
> processing is overwith (response sent, etc.).
> 
> Any suggestions here on what can be done to make this strategy work with 
> the nist stack, for any scenario? The details of the problem reported to 
> us are below. Thanks for any advice or help-
> Becky
> 
> _______________________
> 
> I have been sending in a Subscribe method from a test program using 
> sipunit. The initial subscribe by the nist sip stack calls the 
> SipConnector.processRequest which sends the request to my jiplet in a 
> separate thread.  The problem appears to be related to dialogs and this 
> processing described above.  My jiplet code that processes the Subscribe 
> method uses the dialog to create a response but the processRequest in 
> SipConnector has already returned to deliverEvent in 
> gov.nist.javax.sip.EventScanner.java.  This Nist sip stack should call 
> dialog.requestConsumed() but my jiplet processing isn't finished yet and 
> the next seq nbr in the dialog object doesn't get updated.  This 
> behavior is only discovered when I send in another Subscribe method with 
> the same Callid, toTag, FromTag and a call seq nbr of 2.  The Nist sip 
> stack then looks to see what the next seq no is for that dialog, which 
> should be 2 but the stack sees a one and discards the message.  To see 
> if my theory was correct, I added a sleep(2000) after the for loop in 
> SipConnector.processRequest() and the problem is fixed.  I realize this 
> isn't a good solution but I was just trying to prove my theory.  The 
> problem is related to a new thread being started by the jiplet for 
> processing the Subscribe request.  The new thread hasn't finished 
> updating the dialog reference that the deliverEvent() method is going to 
> use.  I turned off all logging/tracing
>  
> 
> 
> _______________________________________________
> nist-sip mailing list
> [email protected]
> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip