Re: CSEQ checking for SUBSCRIBE/NOTIFY messages

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