[OpenSIPS-Users] OpenSip SIP, SIP-I e SIP-T

[Alex Balashov]

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