[asterisk-ss7] A fix to libss7 bug in SAM construction!

[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 */