In no way shape or form I was defending that behavior as acceptable, just stating some interoperability facts. One FISU each 0,75ms is continuously for 64kbps links. I still don't get it, use dahdi mtp2 kernel feature, and you should get continuous FISUs whenever the link isn't transmitting anything else. Regards, Marcelo Robert Kenton wrote: > Well, according to Q.706 (SS7 Message Transfer Part Signalling > Performance), the emission time is 0,75 ms. > I think this is the interval of sending each FISU message because as > in the Q703 state that "Under normal conditions, when no message > signal units are to be transmitted or retransmitted, fill-in signal > units are sent continuously" > > Robert. > > On Sat, Jul 4, 2009 at 12:32 AM, Gustavo Marsico > <gustavomarsico at gmail.com <mailto:gustavomarsico at gmail.com>> wrote: > > Yes, a few switches acts in that way, but it's very uncommon. As I > tested a few years ago, EWSD in V11 (V13 and V15 works good) and 5ESS > V14 can fail with that behavior. > > Regards, > > Gustavo > > > On Jul 3, 2009, at 8:27 PM, Marcelo Pacheco wrote: > > > I've seen one certified switch for Brazilian ISUP/SS7 (MTP is > > identical > > to ITU-T) the switch is from Digitro that delivers FISUs only 25% of > > link idle time, 75% of idle octets (considering FISUs idle > octets) are > > flags. That switch talked with sucess with Ericsson AXE, Nortel DMS, > > Vectura (operating as an STP), Tropico RA and some others, without > > link > > instability. > > > > Anyhow, libss7 using dahdi mtp2 shouldn't suffer from this issue, as > > well as chan_ss7, as both generate FISUs not stop correctly. > > > > Regards, > > > > Marcelo Pacheco > > > > Kristian Nielsen wrote: > >> "Gustavo Marsico [Gmail]" <gustavomarsico at gmail.com > <mailto:gustavomarsico at gmail.com>> writes: > >> > >> > >>> It's talking about Japan: > >>> > >>> Note: In the ITU-T Japan variant, signaling link quality is > >>> checked by the > >>> continuous transmission of flag octets (8-bit bytes) rather than > >>> FISUs; > >>> FISUs are sent only at predefined timer intervals (e.g., once > >>> every 150 > >>> milliseconds). > >>> > >>> If you live in Japan can make sense that, but in ITU world it's > >>> just like as > >>> Kristian's said. > >>> > >> > >> Yes, I meant ITU SS7. Forgot about the multiple variants ... > >> > >> Here is the relevant quote from ITU Q.703: > >> > >> 11.2.2 For the basic error control method, the priorities are: > >> Highest 1. Link status signal units. > >> 2. Message signal units which have not yet been > >> acknowledged and for which a > >> negative acknowledgement has been received. > >> 3. New message signal units. > >> 4. Fill-in signal units. > >> Lowest 5. Flags. > >> > >> So fill-in signal units are sent unless some serious error prevents > >> sending > >> anything but flags. > >> > >> Don't know about any other variants of SS7. > >> > >> - Kristian. > >> > >> _______________________________________________ > >> --Bandwidth and Colocation Provided by http://www.api-digital.com-- > >> > >> asterisk-ss7 mailing list > >> To UNSUBSCRIBE or update options visit: > >> http://lists.digium.com/mailman/listinfo/asterisk-ss7 > >> > >> > > > > > > _______________________________________________ > > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > > > asterisk-ss7 mailing list > > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-ss7 > > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-ss7 mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-ss7 > > > ------------------------------------------------------------------------ > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-ss7 mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-ss7
|