At what interval should FISUs be sent?

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

 



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




[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