<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Marcelo, <div><br></div><div>Good to see you again here, it's always a pleasure.</div><div><br></div><div><br><div><div>On Mar 16, 2012, at 1:37 PM, Marcelo Pacheco wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Gustavo,<br>
<br>
I think you're confusing the general function of an STP with the
external signaling network architecture used by ANSI countries.<br>
<br>
All incumbent networks in Brazil make heavy usage of STPs.<br>
They have lots of TDM switches, and to avoid a full mesh of
signaling links between all TDM switches that have voice trunks
between them, STPs are used to aggregate SS7 traffic.<br>
<br>
Also STPs are also used as billing entities and for resolving LNP in
some carriers.<br>
<br>
I'm pretty sure STPs have lots of usage in other ITU countries.<br></div></blockquote>Completely agree.</div><div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
However they don't have a fully separate signaling network, 64kbps
SS7 links make maximum usage of semi permanent call setups,
specially for interconnects with other carriers (using bearer
channels of existing E1 voice trunks).<br></div></blockquote>In my previous email I was referring to the different approach to interconnect between switches, if the link goes alone in an E1 or if the link shares the same E1 with CICs. Are we talking about the same? I think you're referring to the physical connections.</div><div><br></div><div>I've some examples by country that I have had to solve (with regular TDM switches and Packetcable Softswitches):</div><div>- For a customer In Fortaleza (very nice beaches!), the incumbent gave us STP connection and asked for a complete E1 for link (they gave us only 1 link), they stated technical reasons. I know that in other cities the incumbents can choose to share the same E1.</div><div>- In Mexico, (early days of ITX) Telmex demanded to use 2 E1 (1 E1 per link), at this time, they force to the carriers to bring up their own STPs, and use B links.</div><div>- In Argentina, Telecom lets you share, and the transit switch performs a semi-permanent (nail-up connection) to reach to the STP. But Telefonica doesn't. So it depends on the incumbent (a bit messy).</div><div>- In Centroamerica (in general terms) they forces to you to share the same E1 if you're local exchange, but if you're transit you _should_ separate signaling and media (seems nobody care of that).</div><div>- In ANSI, for traffic coming from Caribbean in T1 and depending on the US carrier, you can use the same T1 for voice and link.</div><div><br></div><div>As far as I saw, it depends the way the people wants to make the things work.</div><div><br></div><div>Now, if you're talking about real physical connections, you're right, almost everybody shares the same STM-1, but giving different Virtual Containers (or whatever type of connection used) to reach the STP. I've seen cases where the link uses a completely different physical connection. Weird, but exists.</div><div>In the ANSI (US) case depends on the business model of US market, other ANSI markets works in the same way as CALA (or ITU) does.</div><div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
However competitive carriers use redundant soft switch architecture
don't need STPs, since signaling flows through the IP network,
without explicit signaling channels.<br>
<br>
I fell more important than the capability of Asterisk performing as
an STP, is much more important full linkset functionality as a
regular signaling point. For instance, the following scenario can't
be implemented with libss7 today:<br>
<br>
<tt>Asterisk --x-- STP A ---x--- Switch1,2,3,4,5,6,7,8<br>
STP B<br>
</tt><br>
Where Asterisk has voice CICs with all 8 switches, and all signaling
needs to be shared across a pair of signaling links, one with each
STP. Specially with E1s with all 8 switches can't fit on a single
Asterisk box.<br>
<br></div></blockquote></div><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">Marcelo Pacheco<br>
<br>
On 03/15/12 14:39, Gustavo Mársico wrote:
<blockquote cite="mid:F9D4101E-81E6-47A1-9705-41C04F27241D@gmail.com" type="cite"><br>
<div>
<div>On Mar 15, 2012, at 2:17 PM, Michael Mueller wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">STPs in ITU-land are awkward since ITU
voice networks are a mesh of E1 with signaling in the same
bundles as the voice
<div> <br>
<div>in ANSI-land, the STP was incorporated and mandated by
two large and powerful monopolies: BC and ATT; signaling
became de-coupled from the voice and traveling in a
separate network connected by hierarchy of mated pair STPs</div>
<div><br>
</div>
<div>putting an STP or an STP-like invention in an typical
ITU network raises questions about commercial viability:
having a central STP might raise your E1 charges because
they travel over longer distances - this raises monthly
charges in many places; might be cheaper to connect
locally - but then you have increased monthly charges for
colo space</div>
<div><br>
</div>
<div>there is conceptual dissonance between STPs and ITU
networks - STPs require the signaling be separate from the
voice, and ITU mesh networks are built around signaling
and voice channels traveling in the same bundles of wire
(i've just restated my first 2 paragraphs); decoupling
signaling means using an entire E1 for a single signal
channel; this usually causes despair to the typical ITU
ss7 engineer but is business as usual to the ANSI
counterpart</div>
</div>
</blockquote>
This is not quite correct. CALA region mostly uses separate E1
for signalling and media when a STP is used. If STP is not
required, some telco choose to separate and others don't. As the
same as ANSI does. In fact, it's a matter of how the people
wants to make it work.</div>
<div><br>
<br>
<blockquote type="cite">
<div>
<div>the cheapest STP I know of is the PT Segway; maybe you
can get a Tekelec Eagle; I'm not aware of any Linux based
DIY STPs; ss7box started as an STP but evolved away from
the function as there was little need for a low-end STP in
ANSI-land and zero need for it in ITU-land</div>
<div><br>
</div>
<div>ss7box supports Asterisk box clustering around a single
point code with CIC routing; clustering might be something
you want to investigate - you'd have to examine the
technical, commercial, and incumbent connection policies
to see if it would help you build an IP voice network with
fewer connections to the incumbent telco network using
such a clustering function </div>
<div><br>
</div>
<div>you asked a complicated question, or I've turned a
simple question into a complicated one - both are
plausible</div>
<div><br>
<div class="gmail_quote">On Thu, Mar 15, 2012 at 11:45 AM,
Rodrigo Ricardo Passos <span dir="ltr"><<a moz-do-not-send="true" href="mailto:rodrigopassos@gmail.com">rodrigopassos@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Michael,<br>
<br>
Can you explain more?<br>
Here, in Brazil, the standard is ITU. I think it
isn´t possible because ITU is used in all telcos.<br>
<br>
<br>
Em 15/03/2012 12:25, Michael Mueller escreveu:
<div>
<div class="h5">
<blockquote type="cite">connecting a mated pair
of STPs to an ANSI network as a peer has more
requirements than connecting an SSP; ITU STP
are less common so connection requirements
might be more variable<br>
<br>
<div class="gmail_quote">On Thu, Mar 15, 2012
at 10:19 AM, Rodrigo Ricardo Passos <span dir="ltr"><<a moz-do-not-send="true" href="mailto:rodrigopassos@gmail.com" target="_blank">rodrigopassos@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Gustavo,<br>
<br>
Do you know Yate? Knows if Yate can be
used in place of asterisk?<br>
I know that this list is about Asterisk
SS7, but I think that this question
doesn´t bad.<br>
<br>
Regards,<br>
<br>
Rodrigo<br>
<br>
Em 14/03/2012 16:55, Gustavo Mársico
escreveu:
<blockquote type="cite">
<div>There is no pure STP
implementation on libss7 or
chan_ss7. Modules cannot send TFA,
TFP, support STP timers, etc. Today,
all you can do is routing based in
the extensions, but that's not STP
function.</div>
<div>However, I know that some efforts
were made on libss7 and the last
time I checked looked promising.
I'll try to find what's going on
there.</div>
<div><br>
</div>
<div>Regards</div>
<div><br>
</div>
<div>Gustavo</div>
<div><br>
</div>
<br>
<div>
<div>On Mar 14, 2012, at 4:39 PM,
Rodrigo Ricardo Passos wrote:</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> Hi all,<br>
<br><p class="MsoNormal"><span lang="EN-US">I have a
question of how can I create
STPs Boxes with Asterisk in
my network?</span></p><p class="MsoNormal"><span lang="EN-US">My project
includes a creation of
network with asterisk SPs
and STPs and my initial idea
is a implementation of these
boxes using TDMoE. So,
create two boxes like STP e
another’s boxes like SP.</span></p><p class="MsoNormal"><span lang="EN-US">All
signalization will pass to
both STPs. Anyone knows if
my scenario will be one
scenario with a real STP
boxes or this will never STP
ambient?</span></p><p class="MsoNormal"><span lang="EN-US">Other question
is, if this last question is
false, how can I create this
ambient with asterisk?<br>
</span></p><p class="MsoNormal"><br>
Best Regards,<br>
</p><p class="MsoNormal">Rodrigo<br>
<span lang="EN-US"></span></p>
<br>
<span><font color="#888888"> </font></span></div>
<span><font color="#888888"> --<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation
Provided by <a moz-do-not-send="true" 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 moz-do-not-send="true" href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a></font></span></blockquote>
<span><font color="#888888"> </font></span></div>
<span><font color="#888888"> <br>
<br>
<fieldset></fieldset>
<br>
<pre>--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a moz-do-not-send="true" href="http://www.api-digital.com/" target="_blank">http://www.api-digital.com</a> --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
<a moz-do-not-send="true" href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a></pre>
</font></span></blockquote>
</div>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a moz-do-not-send="true" 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 moz-do-not-send="true" href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a><br>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a moz-do-not-send="true" href="http://www.api-digital.com/" target="_blank">http://www.api-digital.com</a> --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
<a moz-do-not-send="true" href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a></pre>
</blockquote>
</div>
</div>
</div>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a moz-do-not-send="true" 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 moz-do-not-send="true" href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a><br>
</blockquote>
</div>
<br>
</div>
</div>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a moz-do-not-send="true" href="http://www.api-digital.com/">http://www.api-digital.com</a>
--<br>
<br>
asterisk-ss7 mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a moz-do-not-send="true" href="http://lists.digium.com/mailman/listinfo/asterisk-ss7">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a></blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com/">http://www.api-digital.com</a> --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-ss7">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a></pre>
</blockquote>
<br>
</div>
--<br>_____________________________________________________________________<br>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">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">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a></blockquote></div><br></div></body></html>