As English is not my native language, I am not sure whether I am right, but I think the term "emission time" is the time it takes to send the messages not the interval at which messages are sent.
From: Robert Kenton
Sent: Saturday, July 04, 2009 11:29 PM
To: asterisk-ss7 at lists.digium.com
Subject: Re: At what interval should FISUs be sent?
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> 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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-ss7/attachments/20090705/43a7c2b9/attachment.htm
|