isup sls bug (isup.c)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On May 15, 2007, at 2:15 PM, Matthew Fredrickson wrote:

>
> On May 15, 2007, at 3:38 AM, sai jayram AKV wrote:
>
>> hi.
>>
>> There is a mistake in isup_send_message function of isup.c
>>
>> rl.sls is assigned sls_next(ss7), assuming there are 16 signaling
>> links amd sls in incrementsd one after other.
>>
>> There will be a problem if the number of signaling links are less 
>> than 16.
>>
>> sls_next may be modified so that 16 is replaced by numlinks.
>
> I have seen many different possible ways of doing this.  I have not 
> seen a good answer yet for how this works.  It Q.763, it says in the 
> spec under section 1.1 (routing label) that the "SLS bits are set to 
> the four least significant bits of the CIC".  Can you point to a 
> specification or document that can verify your recommendation?
>
> It is not exactly correct the way it is written right now.  For ANSI 
> networks, it doesn't do SLS balancing properly across all possible 
> values, and for ITU, it maybe that it need be changed to follow what 
> the ITU recommendation says, instead of the cross ANSI/ITU mix I have 
> currently.

For what it is worth, after doing a little bit of research, I updated 
it (for ITU SS7) to be in accordance with the specifications (using the 
least four significant bits of the CIC) until I hear something else.

Matthew Fredrickson


[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux