[asterisk-dev] Fix to libss7 SAM construction bug

[Tian]

Hi guys,

I am reading libss7 source code and I think I've found a bug in it,
following is my description of the bug and my tentative fix to the bug, as I
don't have a running Asterisk box, I hope you will kindly help me check it,
thanks!

According to ITU-T Recommendation Q.763, section 1.6 'Mandatory variable
part':

"A pointer is also included to indicate the beginning of the optional part.
If the message type indicates that no optional part is allowed, then this
pointer will not be present. If the message type indicates that an optional
part is possible, but there is no optional part included in this particular
message, then a pointer field containing all zeros will be used."

Thus, ISUP messages that don't carry any optionals fall into two categories:
1) those include a 'Pointer to start of optional part' containing all zeros
(e.g., SAM falls into this category) and 2) those don't include a 'Pointer
to start of optional part'.

libss7 can only correctly construct ISUP messages carrying zero optional
parameters that fall into category 2) if messages that fall into category 1)
are to be constructed, libss7 will fail.

The bug shows up in the file isup.c (Libss7 trunk revison 272, lines
2425-2432), my fix to this bug specifically for SAM is as follows (you may
adopt the fix by replacing everyting between the fisrt and the last two
comment lines):

    /* Make sure we grab our opional parameters */
    if (optparams || (messagetype == ISUP_SAM)) {
        if (optparams)
            opt_ptr = &mh->data[offset + varparams];
        /* a SAM message doesn't have any optionals,
         * but the 'Pointer to start of optional part' is still present
         */
        offset += varparams + 1; /* add one for the optionals */
        len -= varparams + 1;
    } else {
        offset += varparams;
        len -= varparams;
    }

    /* Whew, some complicated math for all of these offsets and different
sections */