Re: CSEQ checking for SUBSCRIBE/NOTIFY messages

Thank you, Jeroen!
That fixed it.
Regards,
Becky

Jeroen van Bemmel wrote:

> Hi Becky,
>
> The code you pointed out is simply wrong. The local and remote CSeq 
> spaces are independent, so checking whether a remote request is 
> acceptable should only compare remoteSequenceNumber, never 
> 'this.nextSeqno'
>
> See CVS update
>
> Regards,
>
> Jeroen
>
> PS And thanks for the extensive report
>
> ----- Original Message ----- From: "Becky McElroy" 
> <[email protected]>
> To: <[email protected]>
> Sent: Sunday, May 14, 2006 7:49 PM
> Subject: [nist-sip] CSEQ checking for SUBSCRIBE/NOTIFY messages
>
>
>> Hi-
>>
>> I have this scenario (requests only shown, OK responses are sent but 
>> not shown here):
>>
>> CSeq: 1 SUBSCRIBE ----------->
>>                               <------------CSeq: 1 NOTIFY
>>                               <------------CSeq: 2 NOTIFY
>>                               <------------CSeq: 3 NOTIFY
>> CSeq: 2 SUBSCRIBE------------>
>>
>> In this scenario, the second SUBSCRIBE (refresh) gets dropped by the 
>> stack on the receive side:
>>
>> DEBUG - 
>> gov.nist.javax.sip.NistSipMessageHandlerImpl.processRequest(NistSipMessageHandlerImpl.java:75) 
>> [PROCESSING INCOMING REQUEST SUBSCRIBE 
>> sip:[email protected]:5060;transport=udp SIP/2.0
>> transactionChannel = 
>> gov.nist.javax.sip.stack.SIPServerTransaction@987cd413]
>> DEBUG - 
>> gov.nist.javax.sip.stack.SIPTransactionStack.getDialog(SIPTransactionStack.java:465) 
>> [getDialog([email protected]:[email protected]:1147615033389:[email protected]:1901773286) 
>> : returning gov.nist.javax.sip.stack.SIPDialog@1b8d6f7]
>> DEBUG - 
>> gov.nist.javax.sip.NistSipMessageHandlerImpl.processRequest(NistSipMessageHandlerImpl.java:103) 
>> [dialogId = 
>> [email protected]:[email protected]:1147615033389:[email protected]:1901773286] 
>>
>> DEBUG - 
>> gov.nist.javax.sip.NistSipMessageHandlerImpl.processRequest(NistSipMessageHandlerImpl.java:104) 
>> [dialog = gov.nist.javax.sip.stack.SIPDialog@1b8d6f7]
>> DEBUG - 
>> gov.nist.javax.sip.NistSipMessageHandlerImpl.processRequest(NistSipMessageHandlerImpl.java:423) 
>> [
>> #######
>> Dropping out of sequence in dialog Request
>> ######]
>> DEBUG - 
>> gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:392) 
>> [Done processing SUBSCRIBE sip:[email protected]:5060;transport=udp 
>> SIP/2.0
>> /gov.nist.javax.sip.stack.SIPServerTransaction@987cd413]
>>
>>
>> The reason is because of the final check in this method (ie, 4 is not 
>> <= 2):
>>
>> public boolean isRequestConsumable(SIPRequest dialogRequest) {
>>        // have not yet set remote seqno - this is a fresh
>>        if (dialogRequest.getMethod().equals(Request.ACK))
>>            throw new RuntimeException("Illegal method");
>>        if (this.getRemoteSequenceNumber() == -1)
>>            return true;
>>        else if (this.nextSeqno == null) {
>>            // sipStack.getLogWriter().logDebug( "nextSeqno == null => 
>> refusing
>>            // request" );
>>            return false;
>>        } else
>>            return this.nextSeqno.intValue() <= dialogRequest.getCSeq()
>>                    .getSequenceNumber();
>>    }
>>
>> If I modify isRequestConsumable() to ignore a received SUBSCRIBE, 
>> everything works fine:
>>
>> public boolean isRequestConsumable(SIPRequest dialogRequest) {
>>       if (dialogRequest.getMethod().equals(Request.SUBSCRIBE)) {
>>            return true;
>>        }
>>       // have not yet set remote seqno - this is a fresh
>>        if (dialogRequest.getMethod().equals(Request.ACK))
>>            throw new RuntimeException("Illegal method");
>>        if (this.getRemoteSequenceNumber() == -1)
>>            return true;
>>        else if (this.nextSeqno == null) {
>>            // sipStack.getLogWriter().logDebug( "nextSeqno == null => 
>> refusing
>>            // request" );
>>            return false;
>>        } else
>>            return this.nextSeqno.intValue() <= dialogRequest.getCSeq()
>>                    .getSequenceNumber();
>>    }
>>
>> So, for SUBSCRIBE/NOTIFY (or at least for the notifier side) - it 
>> looks like there can't be an assumed relationship between the number 
>> of SUBSCRIBEs and NOTIFYs sent/received, and the rules need to be a 
>> little different. Would this be the correct fix for this? (Or have I 
>> missed something altogether...).
>>
>> Thanks,
>> Becky
>>
>> _______________________________________________
>> nist-sip mailing list
>> [email protected]
>> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip 
>
>
>