<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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. </div><div><br></div><div><div><div><div><div>On Feb 19, 2009, at 10:39 PM, Alex Balashov wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>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.<br><br>Adrian Georgescu wrote:<br><br><blockquote type="cite">Hm,<br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite">Maybe I am wrong and this has much more sense in the US.<br></blockquote><blockquote type="cite">Adrian<br></blockquote><blockquote type="cite">On Feb 19, 2009, at 8:43 PM, Alex Balashov wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">To expand on this just a little bit:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">One example of this is TransNexus' NexOSS/NexSRS product (<a href="http://www.transnexus.com">www.transnexus.com</a> <<a href="http://www.transnexus.com">http://www.transnexus.com</a>>). 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]."<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Alex Balashov wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Adrian Georgescu wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Why should SIP-T still exist? Is it cheaper than having a gateway? What is the practical use case for investing in such technology?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I am eager to learn<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">We've used it extensively in work with CLECs that operate TDM switches such as the Metaswitch, Lucent LCS/Telica, etc.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">SIP-T is also becoming an attractive external interconnect option.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-- <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Alex Balashov<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Evariste Systems<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Web : <a href="http://www.evaristesys.com/">http://www.evaristesys.com/</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Tel : (+1) (678) 954-0670<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Direct : (+1) (678) 954-0671<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Mobile : (+1) (678) 237-1775<br></blockquote></blockquote><br><br>-- <br>Alex Balashov<br>Evariste Systems<br>Web : <a href="http://www.evaristesys.com/">http://www.evaristesys.com/</a><br>Tel : (+1) (678) 954-0670<br>Direct : (+1) (678) 954-0671<br>Mobile : (+1) (678) 237-1775<br></div></blockquote></div><br></div></div></div></body></html>