<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=iso-8859-1>
<META content="MSHTML 6.00.2900.5803" name=GENERATOR></HEAD>
<BODY id=MailContainerBody
style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px" leftMargin=0
topMargin=0 CanvasTabStop="true" name="Compose message area">
<DIV><FONT face=宋体 size=2>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.</FONT></DIV>
<DIV style="FONT: 10pt Tahoma">
<DIV><BR></DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=robert.kenton@gmail.com
href="mailto:robert.kenton@gmail.com">Robert Kenton</A> </DIV>
<DIV><B>Sent:</B> Saturday, July 04, 2009 11:29 PM</DIV>
<DIV><B>To:</B> <A title=asterisk-ss7@lists.digium.com
href="mailto:asterisk-ss7@lists.digium.com">asterisk-ss7@lists.digium.com</A>
</DIV>
<DIV><B>Subject:</B> Re: [asterisk-ss7] At what interval should FISUs be
sent?</DIV></DIV></DIV>
<DIV><BR></DIV>Well, according to Q.706 (SS7 Message Transfer Part Signalling
Performance), the emission time is 0,75 ms. <BR>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"<BR><BR>Robert.<BR><BR>
<DIV class=gmail_quote>On Sat, Jul 4, 2009 at 12:32 AM, Gustavo Marsico <SPAN
dir=ltr><<A
href="mailto:gustavomarsico@gmail.com">gustavomarsico@gmail.com</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Yes,
a few switches acts in that way, but it's very uncommon. As I<BR>tested a few
years ago, EWSD in V11 (V13 and V15 works good) and 5ESS<BR>V14 can fail with
that behavior.<BR><BR>Regards,<BR><FONT color=#888888><BR>Gustavo<BR></FONT>
<DIV>
<DIV></DIV>
<DIV class=h5><BR><BR>On Jul 3, 2009, at 8:27 PM, Marcelo Pacheco
wrote:<BR><BR>> I've seen one certified switch for Brazilian ISUP/SS7 (MTP
is<BR>> identical<BR>> to ITU-T) the switch is from Digitro that
delivers FISUs only 25% of<BR>> link idle time, 75% of idle octets
(considering FISUs idle octets) are<BR>> flags. That switch talked with
sucess with Ericsson AXE, Nortel DMS,<BR>> Vectura (operating as an STP),
Tropico RA and some others, without<BR>> link<BR>>
instability.<BR>><BR>> Anyhow, libss7 using dahdi mtp2 shouldn't suffer
from this issue, as<BR>> well as chan_ss7, as both generate FISUs not stop
correctly.<BR>><BR>> Regards,<BR>><BR>> Marcelo
Pacheco<BR>><BR>> Kristian Nielsen wrote:<BR>>> "Gustavo Marsico
[Gmail]" <<A
href="mailto:gustavomarsico@gmail.com">gustavomarsico@gmail.com</A>>
writes:<BR>>><BR>>><BR>>>> It's talking about
Japan:<BR>>>><BR>>>> Note: In the ITU-T Japan variant,
signaling link quality is<BR>>>> checked by the<BR>>>>
continuous transmission of flag octets (8-bit bytes) rather
than<BR>>>> FISUs;<BR>>>> FISUs are sent only at predefined
timer intervals (e.g., once<BR>>>> every 150<BR>>>>
milliseconds).<BR>>>><BR>>>> If you live in Japan can make
sense that, but in ITU world it's<BR>>>> just like as<BR>>>>
Kristian's said.<BR>>>><BR>>><BR>>> Yes, I meant ITU SS7.
Forgot about the multiple variants ...<BR>>><BR>>> Here is the
relevant quote from ITU Q.703:<BR>>><BR>>> 11.2.2 For the basic
error control method, the priorities are:<BR>>> Highest 1.
Link status signal units.<BR>>> 2.
Message signal units which have not yet been<BR>>> acknowledged and for
which a<BR>>> negative
acknowledgement has been received.<BR>>>
3. New message signal units.<BR>>>
4. Fill-in signal units.<BR>>> Lowest 5.
Flags.<BR>>><BR>>> So fill-in signal units are sent unless some
serious error prevents<BR>>> sending<BR>>> anything but
flags.<BR>>><BR>>> Don't know about any other variants of
SS7.<BR>>><BR>>> - Kristian.<BR>>><BR>>>
_______________________________________________<BR>>> --Bandwidth and
Colocation Provided by <A href="http://www.api-digital.com--"
target=_blank>http://www.api-digital.com--</A><BR>>><BR>>>
asterisk-ss7 mailing list<BR>>> To UNSUBSCRIBE or update options
visit:<BR>>> <A
href="http://lists.digium.com/mailman/listinfo/asterisk-ss7"
target=_blank>http://lists.digium.com/mailman/listinfo/asterisk-ss7</A><BR>>><BR>>><BR>><BR>><BR>>
_______________________________________________<BR>> --Bandwidth and
Colocation Provided by <A href="http://www.api-digital.com--"
target=_blank>http://www.api-digital.com--</A><BR>><BR>> asterisk-ss7
mailing list<BR>> To UNSUBSCRIBE or update options visit:<BR>> <A
href="http://lists.digium.com/mailman/listinfo/asterisk-ss7"
target=_blank>http://lists.digium.com/mailman/listinfo/asterisk-ss7</A><BR><BR><BR>_______________________________________________<BR>--Bandwidth
and Colocation Provided by <A href="http://www.api-digital.com--"
target=_blank>http://www.api-digital.com--</A><BR><BR>asterisk-ss7 mailing
list<BR>To UNSUBSCRIBE or update options visit:<BR> <A
href="http://lists.digium.com/mailman/listinfo/asterisk-ss7"
target=_blank>http://lists.digium.com/mailman/listinfo/asterisk-ss7</A><BR></DIV></DIV></BLOCKQUOTE></DIV><BR>
<P>
<HR>
<P></P>_______________________________________________<BR>--Bandwidth and
Colocation Provided by http://www.api-digital.com--<BR><BR>asterisk-ss7 mailing
list<BR>To UNSUBSCRIBE or update options visit:<BR>
http://lists.digium.com/mailman/listinfo/asterisk-ss7</BODY></HTML>