[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