[asterisk-dev] zero is a legitimate value for SIP CSeq numbers,
right ?
Kevin P. Fleming
kpfleming at digium.com
Thu Oct 12 10:37:03 MST 2006
----- Luigi Rizzo <rizzo at icir.org> wrote:
> the issue is code obfuscation, which means we don't know
> what the current handling of 0 does, which means trouble :)
Agreed.
> + ocseq is supposed to be initialized to INITIAL_CSEQ (non-zero in
> asterisk),
> so ocseq = 0 is an error condition (if i understand well).
>
> Unfortunately the code near line 14101 does not detect it
> as an error, just accepts incoming packets irrespective
> of the seqno they carry. I think this is a bug.
I don't see any code path where the initreq.headers field in a private structure would be NULL without ocseq having already been initialized to a non-zero value. Since the first check in that code path (which is for handling responses) ensures that the private structure actually holds an outgoing request, this should be a non-issue.
> However CSeq == 0 is a legal initial value for CSeq
> (coming from a third party we have no control over it),
> and if such a message comes in, we would process retransmissions
> of CSeq 0 multiple times because we do not detect it as a dup.
Agreed, but as you say, highly unlikely.
> Other than using an external flag, i think a better
> choice for "not initialized" is 0xffffffff, which is not
> a valid initial CSeq for a dialogue.
It's not a valid value for CSeq, period, not just as an initial value. Any value equal to or greater than 2**31 (0x80000000) is an invalid value. In this case I would agree that making this change is logical.
--
Kevin P. Fleming
Senior Software Engineer
Digium, Inc.
More information about the asterisk-dev
mailing list