Re: [reSIProcate] CSeq is incorrect in NOTIFY generated by DUM on SUBSCRIBE
>>>>> Derek MacDonald <derek.macdonald@xxxxxxxxx> wrote:
> I think we could do something fairly simple(probabilistic) for CSEQ
> roll-overs....if the difference is greater than 2^16, say(or whatever the
> right number is), and the current remote CSeq is 'close' to the edge, treat
> it as a roll-over.
Sorry if I missed some context, but this seems contradicting to
the whole SIP design. If subscriber loses subscription context, it
shall resubscribe and dialog ID will change. If notifier loses
subscription context, it should either try to restore the full
context (e.g. from stable storage) which shall contain also own
CSeq, or forget previous subscription, in that case this is
subscriber's task to check that NOTIFY isn't got when supposed.
With correct implementation according to this design, it doesn't
matter how huge gap between NOTIFY CSeq numbers is; only ordering
check (no less than already received) is important. If notifier
restarts numbering with the same dialog ID but CSeq from smaller
value... one shall beat author of this notifier but don't invent
any unnatural intelligence algorithm (and then resubscribe when
timeout of seeing _correct_ NOTIFY fires).
>>>>>>>> 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.
I agree with opponents of this statement - general dialog design
doesn't suppose any direct correlation between CSeqs of both
sides. It, of course, doesn't prohibit approach when local CSeq is
initially generated on remote CSeq, but this is useless.
--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@xxxxxxxxxxxx