[asterisk-dev] zero is a legitimate value for SIP CSeq numbers, right ?

Luigi Rizzo rizzo at icir.org
Thu Oct 12 10:22:22 MST 2006


On Thu, Oct 12, 2006 at 11:21:52AM -0500, Kevin P. Fleming wrote:
> ----- Luigi Rizzo <rizzo at icir.org> wrote:
> > according to the RFC and a bit of googling on mailing lists,
> > zero (0) seems to be a legitimate value for SIP CSeq numbers,
> > so unless there are objections or other reasons i would like
> > to remove the special handling of 0 for ocseq/icseq in chan_sip.c
> > 
> > Otherwise, if we need to keep it, i would like at least to
> > document why.
> 
> Unless you know of a specific interoperability or performance issue associated with this change, I'm hesitant to see it get changed.

the issue is code obfuscation, which means we don't know
what the current handling of 0 does, which means trouble :)

I see two different issues (refer to SVN44910 of chan_sip.c):

  + 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.

    Since we generally don't checks that variables are correctly
    initialized (we try to guarantee it when we create the
    data structure), i think we should just remove this zero check.

  + icseq is initialized with whatever CSeq we get in the first msg.
    Apparently, in chan_sip, icseq == 0 is used as "not initialized" marker
    (this is in the check for duplicate packets near line 14134).
    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.
    Unlikely but possibly a bug as well.

    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.

Anyways the special handling is only in the two places above,
and my inclination would be to fix them as indicated above.

more convincing ?

	cheers
	luigi


More information about the asterisk-dev mailing list