Oh, I don't. :) I didn't take it that way. I have no personal investment in it whatsoever.
Just trying to help identify the relevance. Adrian Georgescu wrote: > So far SIP-T occurred sporadically on this mailing list. I simply try > identify the relevance of it in this context do not take personally mu > comments. > > On Feb 19, 2009, at 10:39 PM, Alex Balashov wrote: > >> The problem is that outside of the VoIP cottage industry, this stuff >> isn't "legacy" by any stretch of the imagination, in any way, shape, >> or form. We're just used to fancifully imagining that it is. >> >> Adrian Georgescu wrote: >> >>> Hm, >>> It is very hard to judge the benefits of performing all the nice to >>> have feature at a higher level protocol while still having to support >>> legacy expensive infrastructure underneath. >>> Now, last time I heard about SIP-T was by an ECMA standard a few >>> years ago. ECMA is a sort of inverse pyramid European standards body >>> that nobody listens to. Basically, they are sponsored by vendors to >>> endorse 'standards' because they posses an EU stamp. The word here in >>> Europe goes that if something went to the extent of geting an ECMA >>> official endorsement, one knows that it is a standard with no future >>> and no company invests in it anymore. >>> Maybe I am wrong and this has much more sense in the US. >>> Adrian >>> On Feb 19, 2009, at 8:43 PM, Alex Balashov wrote: >>>> To expand on this just a little bit: >>>> >>>> While here in the VoIP cottage industry we mostly deal with SIP to >>>> begin with, in that we use ISDN gateways for connecting to carriers, >>>> get SIP trunking from our carriers/ITSPs, and so on, the reality is >>>> that most stuff in the PSTN carrier space is still done with >>>> big-iron TDM equipment, at least here in the US. If you want to be >>>> a competitive carrier, you *must* interconnect with the incumbent >>>> telco using SS7; no ands, buts, ors. >>>> >>>> That doesn't mean there aren't a lot of opportunities to deploy SIP >>>> internally inside the service delivery core. The main benefit SIP >>>> provides there is that it is so high-level and easy to manipulate. >>>> As a result, a lot of mediation, logging, billing, analysis, >>>> translation, LCR can be done easily and inexpensively. Before SIP >>>> and H.323 came along, doing this kind of stuff required a box that >>>> did all that and spoke SS7 or, at the very least ISDN Q.931, and >>>> that is much more expensive, inflexible, and difficult to manipulate. >>>> >>>> Promoting this traffic to a higher-level protocol stack that has >>>> more applications and tools to deal with it allows the development >>>> of solutions for doing sophisticated telco-world stuff using >>>> commodity hardware and open methodologies, open-source style. That >>>> has triggered a wave of new products and paradigms in the telco >>>> space in a way that is analogous to how Asterisk et al have >>>> revolutionised the PBX space. >>>> >>>> One example of this is TransNexus' NexOSS/NexSRS product >>>> (www.transnexus.com <http://www.transnexus.com> >>>> <http://www.transnexus.com>). They use the OSP (Open Settlement >>>> Protocol) module for OpenSER and/or for Asterisk (depending on >>>> whether a B2BUA is required) internally inside their product to >>>> perform a lot of neat AAA and routing functions (e.g. the NexSRS >>>> route server). Their ability to do this benefits precisely from the >>>> fact that the traffic can be moved onto a higher-level protocol >>>> plane and away from proprietary, expensive, closed and inflexible >>>> stuff that has been a defining feature of the telco world. If you >>>> can turn the traffic into SIP or H.323, they can deal with it, but >>>> if it's SS7 or PRI, they can't. The world is going more "soft[ware]." >>>> >>>> At the same time, the telco space is not a SIP world right now; the >>>> network edges are still SS7, and the market really hasn't settled on >>>> a good private SIP interconnection/peering strategy and >>>> implementation for intercarrier settlement. So, for the most part >>>> SIP trunking is used for customer access only. The SS7 information >>>> must be conserved in this type of setup, and that's one of the >>>> reasons the sort of thing that SIP-T is exists. >>>> >>>> Alex Balashov wrote: >>>> >>>>> Adrian Georgescu wrote: >>>>>> Why should SIP-T still exist? Is it cheaper than having a gateway? >>>>>> What is the practical use case for investing in such technology? >>>>>> >>>>>> I am eager to learn >>>>> We've used it extensively in work with CLECs that operate TDM >>>>> switches such as the Metaswitch, Lucent LCS/Telica, etc. >>>>> When a carrier operates more than one switch, SS7 interconnection >>>>> between them is generally required so, for the same basic reasons >>>>> an internal iBGP mesh or partial mesh (confederation) between two >>>>> border routers is required for IP. One switch must be aware of >>>>> numbers routed or ported into the other switch, and so on. >>>>> The reason for its existence is that if both network elements >>>>> support SIP-T, it allows you to replace an SS7 IMT (inter-machine >>>>> trunk) with an IP-based mechanism for this interconnection. This >>>>> allows you to move the traffic over a data network and get all the >>>>> benefits that this brings; economies of scale through decreased >>>>> facilities, oversubscription, etc. The main benefit is the >>>>> elimination of TDM trunk exhaust; SS7 IMTs are physically bundles >>>>> (trunk groups/TCICs) of DS0s, usually consisting of one or more >>>>> T1s, and sometimes DS3s or more. That means that when a large >>>>> volume of calls is running between the two switches, you could burn >>>>> up all your SS7 trunks. Running the calls as SIP-T allows you to >>>>> use something like a gigabit network core to make that problem go >>>>> away somewhat -- a key benefit of VoIP in most other scenarios with >>>>> which you are familiar with. >>>>> At the same time, the switches still need ISUP attributes carried >>>>> in SS7 IAMs and ACMs for billing, because that's just the >>>>> information they operate on internally. SIP-T provides an IP-based >>>>> way to encapsulate that information. >>>>> SIGTRAN (essentially, SS7-over-IP) is another way to do this. >>>>> However, SIP-T is lightweight and easier to deploy. It also >>>>> allows you to use existing SIP network elements (proxies, session >>>>> border controllers, etc.) to route and manage the traffic. For >>>>> example, if you were using OpenSIPS + ACC + FreeRADIUS as a CDR >>>>> catcher, you could run the "SS7" calls between two switches and log >>>>> the appropriate information as custom attributes. There are no >>>>> good open-source implementations for SIGTRAN - nothing as turn-key >>>>> as Kamailio or OpenSIPS. SIP is high-level and much easier to deal >>>>> with and manipulate using a far wider range of tools. >>>>> SIP-T is also becoming an attractive external interconnect option. >>>> >>>> >>>> -- >>>> Alex Balashov >>>> Evariste Systems >>>> Web : http://www.evaristesys.com/ >>>> Tel : (+1) (678) 954-0670 >>>> Direct : (+1) (678) 954-0671 >>>> Mobile : (+1) (678) 237-1775 >> >> >> -- >> Alex Balashov >> Evariste Systems >> Web : http://www.evaristesys.com/ >> Tel : (+1) (678) 954-0670 >> Direct : (+1) (678) 954-0671 >> Mobile : (+1) (678) 237-1775 > -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
