[reSIProcate] CSeq is incorrect in NOTIFY generated by DUM on SUBSCRIBE

[Adam Roach]

Volodymyr:

Thanks for the suggestion.

In terms of the local CSeq: According to RFC 3261, The CSeq number space 
is unique in each direction. In other words, the CSeq in the NOTIFY is 
completely unrelated to the CSeq in the SUBSCRIBE. The original code is 
correct.

I agree with you that the remote CSeq is not used, and can likely be 
removed. I'd be interested to have Scott, Jason, and Derek weigh in on 
whether this can be safely removed, or if there are some future plans 
for it.

/a

Volodymyr Tarasenko wrote:
> Hi All,
>
> As I see dum is incorrectly generates CSeq in NOTIFY in case when SUBSCRIBE's SCeq was not 1. NOTIFY's CSeq always starts from 2 in spite of CSeq in SUBSCRIBE was not 1.
>  
> The fast patch is very simple:
>
> --- resip/dum/Dialog.cxx
> +++ resip/dum/Dialog.cxx
> @@ -136,7 +136,7 @@
>        }
>
>        mRemoteCSeq = request.header(h_CSeq).sequence();
> -      mLocalCSeq = 1;
> +      mLocalCSeq = request.header(h_CSeq).sequence();
>
>        DebugLog ( << "************** Created Dialog as UAS **************" );
>        DebugLog ( << "mRemoteNameAddr: " << mRemoteNameAddr );
>
> Also, after code review I've found that mRemoteCSeq is never used and looks like it could be safety removed.
>
> Regards,
> Volodymyr!
>
>
>       
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>