Re: Incoming SIP message handling

Hi Becky,

According to the SIP spec, in-dialog requests can only be consumed in 
CSeq order so it is acceptable behavior for the stack to reject the next 
in-dialog request if it arrives early (i.e - reject CSeq 2. If you want, 
you can switch to Jain SIP 1.2 and manage your own dialog layer. This 
will allow you to process requests in any order you wish as there will 
be no dialog associated with the incoming request.

Regards,

Ranga



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



-- 
M. Ranganathan 

Advanced Networking Technologies Division,
National Institute of Standards and Technology (NIST),
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/
Advanced Networking Technologies For the People!