Hi Marcelo, Good to see you again here, it's always a pleasure. On Mar 16, 2012, at 1:37 PM, Marcelo Pacheco wrote: > Gustavo, > > I think you're confusing the general function of an STP with the external signaling network architecture used by ANSI countries. > > All incumbent networks in Brazil make heavy usage of STPs. > 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. > > Also STPs are also used as billing entities and for resolving LNP in some carriers. > > I'm pretty sure STPs have lots of usage in other ITU countries. Completely agree. > > 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). 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. I've some examples by country that I have had to solve (with regular TDM switches and Packetcable Softswitches): - 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. - 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. - 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). - 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). - 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. As far as I saw, it depends the way the people wants to make the things work. 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. 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. > > However competitive carriers use redundant soft switch architecture don't need STPs, since signaling flows through the IP network, without explicit signaling channels. > > 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: > > Asterisk --x-- STP A ---x--- Switch1,2,3,4,5,6,7,8 > STP B > > 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. > > Marcelo Pacheco > > On 03/15/12 14:39, Gustavo M?rsico wrote: >> >> >> On Mar 15, 2012, at 2:17 PM, Michael Mueller wrote: >> >>> STPs in ITU-land are awkward since ITU voice networks are a mesh of E1 with signaling in the same bundles as the voice >>> >>> 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 >>> >>> 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 >>> >>> 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 >> 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. >> >> >>> 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 >>> >>> 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 >>> >>> you asked a complicated question, or I've turned a simple question into a complicated one - both are plausible >>> >>> On Thu, Mar 15, 2012 at 11:45 AM, Rodrigo Ricardo Passos <rodrigopassos at gmail.com> wrote: >>> Michael, >>> >>> Can you explain more? >>> Here, in Brazil, the standard is ITU. I think it isn?t possible because ITU is used in all telcos. >>> >>> >>> Em 15/03/2012 12:25, Michael Mueller escreveu: >>>> 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 >>>> >>>> On Thu, Mar 15, 2012 at 10:19 AM, Rodrigo Ricardo Passos <rodrigopassos at gmail.com> wrote: >>>> Gustavo, >>>> >>>> Do you know Yate? Knows if Yate can be used in place of asterisk? >>>> I know that this list is about Asterisk SS7, but I think that this question doesn?t bad. >>>> >>>> Regards, >>>> >>>> Rodrigo >>>> >>>> Em 14/03/2012 16:55, Gustavo M?rsico escreveu: >>>>> >>>>> 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. >>>>> 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. >>>>> >>>>> Regards >>>>> >>>>> Gustavo >>>>> >>>>> >>>>> On Mar 14, 2012, at 4:39 PM, Rodrigo Ricardo Passos wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I have a question of how can I create STPs Boxes with Asterisk in my network? >>>>>> >>>>>> 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. >>>>>> >>>>>> 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? >>>>>> >>>>>> Other question is, if this last question is false, how can I create this ambient with asterisk? >>>>>> >>>>>> >>>>>> Best Regards, >>>>>> Rodrigo >>>>>> >>>>>> >>>>>> -- >>>>>> _____________________________________________________________________ >>>>>> -- 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 >>> >>> -- >>> _____________________________________________________________________ >>> -- 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/20120316/fb0a0bdf/attachment-0001.htm>
|